CloudEngine 6800 V200R005C20 Configuration Guide - IP Multicast

CloudEngine 6800 Series Switches
V200R005C20
Configuration Guide - IP Multicast
Issue 02
Date 2019-10-15
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2019. 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: https://e.huawei.com
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. i

Configuration Guide - IP Multicast About This Document
About This Document
Intended Audience
This document is intended for network engineers responsible for CE series switches
configuration and management. You should be familiar with basic Ethernet knowledge and
have extensive experience in network deployment and management.
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates a potentially hazardous situation

which, if not avoided, could result in
equipment damage, data loss, performance
deterioration, or unanticipated results.
NOTICE is used to address practices not
related to personal injury.
Supplements the important information in

the main text.
NOTE is used to address information not
related to personal injury, equipment
damage, and environment deterioration.
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.
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. ii

Convention Description
[] 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. Several items or no item can be selected.
&<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.
Security Conventions
l Password setting
– When configuring a password, the cipher text is recommended. To ensure device
security, change the password periodically.
– When you configure a password in plain text that starts and ends with %^%#......%^
%# (the password can be decrypted by the device), the password is displayed in the
same manner as the configured one in the configuration file. Do not use this setting.
After the system master key is set using the set master-key command, do not start
and end the key with %@%# because the string starting and ending with %@%#
is considered as a valid cipher-text key.
– When you configure a password in cipher text, different features cannot use the
same cipher-text password. For example, the cipher-text password set for the AAA
feature cannot be used for other features.
– After the system software is downgraded and the switch restarts with the
configuration of the higher version, AAA, VTY, serial interface login, and SNMP
user passwords become invalid. As a result, users fail to log in to the switch using
the passwords and the switch is disconnected from the network management
system.
To address this problem, take the following measures:
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. iii

i. If no password is configured for the console port, log in to the device through
the console port, and reconfigure AAA and password for users such as VTY
and SNMP users. For security purposes, the console port password is
recommended.
ii. If a password is configured for login through the console port, the password
becomes invalid after the downgrade and you cannot log in to the switch
through the console port. In the case of downgrade to a version later than
V200R005C10, contact Huawei technical support engineers for assistance. If
the version is downgraded to V200R005C10 or an earlier version, perform the
following steps to resolve the issue:
1) Connect to the console port.
2) Power cycle the device. During the startup, enter Ctrl+B according to the
prompt to enter the BIOS menu. The default password is
Admin@huawei.com.
3) Select 7.Modify console password to delete and change the console port
password.
4) Restart the device, log in to the device through the console port, and
reconfigure the password for AAA, VTY, or SNMP user.
l Encryption algorithm
Currently, the device uses the following encryption algorithms: DES, 3DES, AES, DSA,
RSA, DH, ECDH, HMAC, SHA1, SHA2, PBKDF2, scrypt, and MD5. The encryption
algorithm depends on the applicable scenario. Use the recommended encryption
algorithm; otherwise, security defense requirements may be not met.
– For the symmetrical encryption algorithm, use AES with the key of 256 bits or
more.
– When you need to use an asymmetric cryptography, RSA (2048-bit or longer key)
is recommended. In addition, use different key pairs for encryption and signature.
– For the digital signature, RSA (2048-bit or longer key) or DSA (2048-bit or longer
key) is recommended.
– For key negotiation, DH (2048-bit or longer key) or ECDH (256-bit or longer key)
is recommended.
– For the hash algorithm, use SHA with the key of 256 bits or more.
– For the HMAC algorithm, use HMAC-SHA2.
– DES, 3DES, RSA and AES are reversible encryption algorithm. If protocols are
used for interconnection, the locally stored password must be reversible.
– SHA1, SHA2, and MD5 are irreversible encryption algorithm. When configuring a
password for local administrator, it is recommended that you use the SHA2
irreversible encryption algorithm.
– To prevent brute force cracking of the user password, the iteration algorithm is
added to the password on the basis of salts. The iteration algorithm uses PBKDF2
or scrypt key export algorithm.
– The ECB mode has a poor capability of defending against plaintext playback
attacks, so ECB is not recommended for password encryption.
– In SSH2.0, the symmetric cryptography using the CBC mode may undergo the
plaintext-recovery attack to cause a data leak. Therefore, the CBC mode is not
recommended for SSH2.0.
l Personal data
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. iv

Some personal data (such as MAC or IP addresses of terminals) may be obtained or used
during operation or fault location of your purchased products, services, features, so you
have an obligation to make privacy policies and take measures according to the
applicable law of the country to protect personal data.
l The terms mirrored port, port mirroring, traffic mirroring, and mirroring in this manual
are mentioned only to describe the product's function of communication error or failure
detection, and do not involve collection or processing of any personal information or
communication data of users.
Reference Standards and Protocols

To obtain reference standards and protocols, log in to Huawei official website, search for
"protocol compliance list", and download the Huawei CloudEngine Switches Protocol
Compliance List.
Declaration
l This manual is only a reference for you to configure your devices. The contents in the
manual, such as command line syntax, and command outputs, are based on the device
conditions in the lab. The manual provides instructions for general scenarios, but do not
cover all usage scenarios of all product models. The contents in the manual may be
different from your actual device situations due to the differences in software versions,
models, and configuration files. The manual will not list every possible difference. You
should configure your devices according to actual situations.
l The specifications provided in this manual are tested in lab environment (for example,
the tested device has been configured with a certain type of cards or only one protocol is
run on the device). Results may differ from the listed specifications when you attempt to
obtain the maximum values with multiple functions enabled on the device.
l In this document, public IP addresses may be used in feature introduction and
configuration examples and are for reference only unless otherwise specified.
Mappings between Product Software Versions and NMS

Versions
The mappings between product software versions and NMS versions are as follows.
CloudEngine 6800 series NMS

switches Product Software
Version
V200R005C20 Contact technical support personnel.
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. v

Mappings between Product Software Versions and

Controller Versions
The mappings between product software versions and Controller versions are as follows.
CloudEngine 6800 series Controller

switches Product Software
Version
V200R005C20 Agile Controller-DCN V300R019C00
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. vi

Configuration Guide - IP Multicast Contents
Contents
About This Document.....................................................................................................................ii

1 IP Multicast Basics........................................................................................................................ 1
1.1 Overview of IP Multicast............................................................................................................................................... 1
1.2 Understanding IP Multicast............................................................................................................................................ 4
1.2.1 Multicast Concept........................................................................................................................................................4
1.2.2 Multicast Service Models............................................................................................................................................ 5
1.2.3 Multicast Addresses.....................................................................................................................................................6
1.2.4 IPv4 Multicast Protocols............................................................................................................................................11
1.3 Application Scenarios for IP Multicast........................................................................................................................ 13
1.3.1 Multicast Deployment on an IPv4 Network.............................................................................................................. 14
2 IGMP Configuration...................................................................................................................20
2.1 Overview of IGMP....................................................................................................................................................... 20
2.2 Understanding IGMP....................................................................................................................................................21
2.2.1 IGMP Versions.......................................................................................................................................................... 21
2.2.2 IGMPv1 Fundamentals..............................................................................................................................................22
2.2.3 Changes in IGMPv2.................................................................................................................................................. 25
2.2.4 Changes in IGMPv3.................................................................................................................................................. 29
2.2.5 IGMP SSM Mapping.................................................................................................................................................35
2.3 Application Scenarios for IGMP.................................................................................................................................. 36
2.3.1 Typical IGMP Application........................................................................................................................................ 36
2.4 Summary of IGMP Configuration Tasks......................................................................................................................38
2.5 Licensing Requirements and Limitations for IGMP.................................................................................................... 38
2.6 Default Settings for IGMP............................................................................................................................................43
2.7 Configuring Basic IGMP Functions............................................................................................................................. 43
2.7.1 Enabling IGMP..........................................................................................................................................................43
2.7.2 Configuring the IGMP Version..................................................................................................................................46
2.7.3 (Optional) Configuring a Static IGMP Multicast Group on an Interface..................................................................48
2.7.4 (Optional) Configuring the Range of IPv4 Multicast Groups That an Interface Can Join........................................49
2.7.5 Verifying the Basic IGMP Function Configuration...................................................................................................50
2.8 Optimizing IGMP Performance....................................................................................................................................51
2.8.1 Configuring the IPv4 Router-Alert Option................................................................................................................51
2.8.2 Configuring IGMP Querier Parameters.....................................................................................................................53
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. vii

2.8.3 Configuring IGMP Fast Leave.................................................................................................................................. 57

2.8.4 Configuring IGMP On-Demand................................................................................................................................ 58
2.8.5 Configuring IGMP Host Tracking.............................................................................................................................59
2.8.6 Filtering IGMP Messages Based on Source IPv4 Addresses.................................................................................... 60
2.8.7 Verifying the Configuration of IGMP Performance Parameters............................................................................... 62
2.9 Configuring IGMP SSM Mapping............................................................................................................................... 62
2.10 Maintaining IGMP......................................................................................................................................................64
2.10.1 Resetting IGMP Group Memberships..................................................................................................................... 64
2.10.2 Resetting IGMP Packet Statistics............................................................................................................................ 65
2.10.3 Monitoring the IGMP Running Status.....................................................................................................................65
2.11 Configuration Examples for IGMP.............................................................................................................................66
2.11.1 Example for Configuring Basic IGMP Functions................................................................................................... 66
2.11.2 Example for Configuring a Static IPv4 Multicast Group on an Interface............................................................... 73
2.11.3 Example for Configuring IGMP SSM Mapping......................................................................................................78
2.12 Troubleshooting IGMP............................................................................................................................................... 85
2.12.1 IGMP Entries Cannot Be Created........................................................................................................................... 85
2.12.2 (S, G) Entries Are Not Generated After IGMP SSM Mapping Is Enabled.............................................................86
3 IPv4 PIM Configuration............................................................................................................. 87

3.1 Overview of PIM.......................................................................................................................................................... 87
3.2 Understanding PIM.......................................................................................................................................................88
3.2.1 Concepts.................................................................................................................................................................... 88
3.2.2 PIM-DM.................................................................................................................................................................... 90
3.2.3 PIM-SM (ASM Model)............................................................................................................................................. 97
3.2.4 PIM-SM (SSM Model)............................................................................................................................................ 106
3.2.5 Bidir-PIM.................................................................................................................................................................108
3.2.6 PIM BFD..................................................................................................................................................................118
3.3 Application Scenarios for PIM................................................................................................................................... 119
3.3.1 PIM-DM Application in a Single AS...................................................................................................................... 119
3.3.2 PIM-SM Application in a Single AS....................................................................................................................... 120
3.3.3 Bidir-PIM Application in a Single AS.....................................................................................................................122
3.4 Summary of IPv4 PIM Configuration Tasks.............................................................................................................. 123
3.5 Licensing Requirements and Limitations for IPv4 PIM.............................................................................................124
3.6 Default Settings for IPv4 PIM.................................................................................................................................... 131
3.7 Configuring IPv4 PIM-DM........................................................................................................................................ 132
3.7.1 Configuring Basic IPv4 PIM-DM Functions...........................................................................................................132
3.7.2 Setting the Lifetime of a Multicast Source in IPv4 PIM-DM................................................................................. 134
3.7.3 Adjusting Control Parameters for Establishing Neighbor Relationships in IPv4 PIM-DM....................................135
3.7.3.1 Adjusting Time Parameters for Hello Messages.................................................................................................. 135
3.7.3.2 Configuring an Interface to Reject Hello Messages Without a Generation ID.................................................... 137
3.7.3.3 Verifying the Configuration of Control Parameters for Establishing Neighbor Relationships in IPv4 PIM-DM
.......................................................................................................................................................................................... 138
3.7.4 Adjusting Control Parameters for Prune Messages in IPv4 PIM-DM.................................................................... 139
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. viii

3.7.4.1 Adjusting Time Parameters for Join/Prune Messages.......................................................................................... 139

3.7.4.2 Disabling PIM Join/Prune Message Packaging....................................................................................................141
3.7.4.3 Adjusting Control Parameters for Prune Delay.................................................................................................... 141
3.7.4.4 Verifying the Configuration of Control Parameters for Prune Messages in IPv4 PIM-DM................................ 143
3.7.5 Adjusting Graft Control Parameters in IPv4 PIM-DM........................................................................................... 144
3.7.6 Adjusting State Refresh Control Parameters in IPv4 PIM-DM.............................................................................. 145
3.7.6.1 Disabling Forwarding of State-Refresh Messages............................................................................................... 146
3.7.6.2 Adjusting Time Parameters for State-Refresh Messages..................................................................................... 147
3.7.6.3 Setting the TTL Value of State-Refresh Messages............................................................................................... 148
3.7.6.4 Verifying the Configuration of State Refresh Control Parameters in IPv4 PIM-DM...........................................149
3.7.7 Adjusting Assert Control Parameters in IPv4 PIM-DM..........................................................................................150
3.7.8 Configuring a Limit on the Number of IPv4 PIM-DM Entries............................................................................... 152
3.8 Configuring IPv4 PIM-SM......................................................................................................................................... 153
3.8.1 Configuring IPv4 PIM-SM in the ASM Model.......................................................................................................153
3.8.1.1 Enabling PIM-SM.................................................................................................................................................153
3.8.1.2 Configuring an RP................................................................................................................................................ 156
3.8.1.3 (Optional) Configuring a BSR Administrative Domain.......................................................................................159
3.8.1.4 (Optional) Configuring the SPT Switchover Condition....................................................................................... 161
3.8.1.5 (Optional) Adjusting Control Parameters for Source Registration...................................................................... 162
3.8.1.6 (Optional) Adjusting C-RP Control Parameters................................................................................................... 165
3.8.1.7 (Optional) Adjusting C-BSR Control Parameters................................................................................................ 166
3.8.1.8 Verifying the Configuration of IPv4 PIM-SM in the ASM Model.......................................................................167
3.8.2 Configuring IPv4 PIM-SM in the SSM Model....................................................................................................... 168
3.8.2.1 Enabling PIM-SM.................................................................................................................................................168
3.8.2.2 (Optional) Configuring an SSM Group Policy.....................................................................................................171
3.8.2.3 Verifying the Configuration of IPv4 PIM-SM in the SSM Model....................................................................... 171
3.8.3 Adjusting Control Parameters for a Multicast Source in IPv4 PIM-SM................................................................. 172
3.8.4 Adjusting Control Parameters for Establishing Neighbor Relationships in IPv4 PIM-SM.................................... 174
3.8.4.1 Adjusting Control Parameters for Hello Messages.............................................................................................. 175
3.8.4.2 Configuring PIM Neighbor Filtering....................................................................................................................177
3.8.4.3 Verifying the Configuration of Control Parameters for Establishing Neighbor Relationships in IPv4 PIM-SM
.......................................................................................................................................................................................... 178
3.8.5 Adjusting Control Parameters for DR Election in IPv4 PIM-SM........................................................................... 178
3.8.5.1 Configuring the DR Priority................................................................................................................................. 179
3.8.5.2 Configuring the DR Switchover Delay................................................................................................................ 180
3.8.5.3 Verifying the Configuration of Control Parameters for DR Election in IPv4 PIM-SM....................................... 181
3.8.6 Adjusting Control Parameters for Join/Prune Messages in IPv4 PIM-SM............................................................. 182
3.8.6.4 Configuring a Join Information Filtering Policy.................................................................................................. 187
3.8.6.5 Verifying the Configuration of Control Parameters for Join/Prune Messages in IPv4 PIM-SM......................... 188
3.8.7 Adjusting Assert Control Parameters in IPv4 PIM-SM.......................................................................................... 189
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. ix

3.8.8 Configuring IPv4 PIM-SM Anycast RP.................................................................................................................. 191

3.8.8.1 Configuring Global Anycast RP...........................................................................................................................192
3.8.8.2 Configuring Local Addresses for Anycast RPs.................................................................................................... 192
3.8.8.3 Configuring Anycast RP Peers............................................................................................................................. 193
3.8.8.4 Verifying the IPv4 PIM-SM Anycast RP Configuration...................................................................................... 194
3.8.9 Configuring IPv4 PIM BFD.................................................................................................................................... 194
3.8.10 Configuring IPv4 PIM Silent.................................................................................................................................196
3.8.11 Configuring IPv4 PIM IPSec.................................................................................................................................198
3.8.11.1 Configuring Basic IPSec Functions....................................................................................................................198
3.8.11.2 Configuring PIM IPSec...................................................................................................................................... 201
3.8.11.3 Verifying the IPv4 PIM IPSec Configuration..................................................................................................... 203
3.8.12 Configuring a Limit on the Number of IPv4 PIM-SM Entries..............................................................................203
3.8.13 Configuring a Device Not to Switch Multicast Traffic Back to the Original Link After ECMP Link Switchover
.......................................................................................................................................................................................... 204
3.9 Configuring IPv4 Bidir-PIM.......................................................................................................................................205
3.9.1 Configuring Basic IPv4 Bidir-PIM Functions.........................................................................................................206
3.9.1.1 Enabling Bidir-PIM.............................................................................................................................................. 206
3.9.1.2 Configuring an RP................................................................................................................................................ 208
3.9.1.3 (Optional) Configuring a BSR Administrative Domain.......................................................................................212
3.9.1.4 (Optional) Adjusting C-RP Control Parameters................................................................................................... 214
3.9.1.5 (Optional) Adjusting C-BSR Control Parameters................................................................................................ 215
3.9.1.6 Verifying the Basic IPv4 Bidir-PIM Function Configuration...............................................................................217
3.9.2 Adjusting Control Parameters for a Multicast Source in IPv4 Bidir-PIM...............................................................217
3.9.3 Adjusting Control Parameters for Establishing Neighbor Relationships in IPv4 Bidir-PIM.................................. 219
3.9.3.1 Adjusting Control Parameters for Hello Messages.............................................................................................. 220
3.9.3.2 Configuring PIM Neighbor Filtering....................................................................................................................221
3.9.3.3 Verifying the Configuration of Control Parameters for Establishing Neighbor Relationships in IPv4 Bidir-PIM
.......................................................................................................................................................................................... 223
3.9.4 Adjusting Control Parameters for DF Election in IPv4 Bidir-PIM......................................................................... 223
3.9.4.1 Configuring the Interval Between Offer Messages.............................................................................................. 224
3.9.4.2 Configuring the Interval Between Backoff Messages.......................................................................................... 225
3.9.4.3 Configuring the DF Election Robustness Variable...............................................................................................227
3.9.4.4 Verifying the Configuration of Control Parameters for DF Election in IPv4 Bidir-PIM..................................... 229
3.9.5 Adjusting Control Parameters for Join/Prune Messages in IPv4 Bidir-PIM...........................................................229
3.9.5.4 Configuring a Join Information Filtering Policy.................................................................................................. 234
3.9.5.5 Verifying the Configuration of Control Parameters for Join/Prune Messages in IPv4 Bidir-PIM....................... 235
3.9.6 Configuring IPv4 PIM BFD.................................................................................................................................... 236
3.9.7 Configuring IPv4 PIM Silent...................................................................................................................................238
3.9.8 Configuring IPv4 PIM IPSec...................................................................................................................................240
3.9.8.1 Configuring Basic IPSec Functions......................................................................................................................240
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. x

3.9.8.2 Configuring PIM IPSec........................................................................................................................................ 242

3.9.8.3 Verifying the IPv4 PIM IPSec Configuration.......................................................................................................245
3.9.9 Configuring a Limit on the Number of IPv4 Bidir-PIM Entries............................................................................. 245
3.10 Maintaining IPv4 PIM-DM...................................................................................................................................... 246
3.10.1 Clearing Statistics About IPv4 PIM Control Packets............................................................................................ 246
3.10.2 Monitoring the IPv4 PIM-DM Running Status..................................................................................................... 246
3.11 Maintaining IPv4 PIM-SM....................................................................................................................................... 247
3.11.2 Clearing the PIM Status of the Specified Downstream Interfaces in IPv4 PIM Entries....................................... 248
3.11.3 Clearing IPSec Packet Statistics............................................................................................................................ 248
3.11.4 Monitoring the IPv4 PIM-SM Running Status...................................................................................................... 248
3.12 Maintaining IPv4 Bidir-PIM.....................................................................................................................................250
3.12.2 Clearing the PIM Status of the Specified Downstream Interfaces in IPv4 PIM Entries....................................... 250
3.12.3 Clearing IPSec Packet Statistics............................................................................................................................ 251
3.12.4 Monitoring the IPv4 Bidir-PIM Running Status................................................................................................... 251
3.13 Configuration Examples for IPv4 PIM.....................................................................................................................252
3.13.1 Example for Configuring Basic IPv4 PIM-DM Functions....................................................................................252
3.13.2 Example for Configuring IPv4 PIM-SM in the ASM Model................................................................................ 259
3.13.3 Example for Configuring IPv4 PIM-SM in the SSM Model.................................................................................269
3.13.4 Example for Configuring Anycast RP Using IPv4 PIM........................................................................................277
3.13.5 Example for Configuring Basic IPv4 Bidir-PIM Functions.................................................................................. 284
3.13.6 Example for Configuring IPv4 Bidir-PIM and IPv4 PIM-SM on the Same Network.......................................... 291
3.13.7 Example for Configuring IPv4 Layer 3 Multicast over M-LAG...........................................................................297
3.14 Troubleshooting IPv4 PIM....................................................................................................................................... 308
3.14.1 SPT on an IPv4 PIM-DM Network Fails to Be Established................................................................................. 308
3.14.2 RPT on an IPv4 PIM-SM Network Fails to Be Established..................................................................................308
3.14.3 SPT on an IPv4 PIM-SM Network Fails to Be Established.................................................................................. 311
3.14.4 After the Source DR Sends a Register Message to the RP, the Registration Interface Still Exists in the
Corresponding Multicast Forwarding Entry.....................................................................................................................314
4 MSDP Configuration................................................................................................................ 316

4.1 Overview of MSDP.................................................................................................................................................... 316
4.2 Understanding MSDP.................................................................................................................................................317
4.2.1 MSDP Peers.............................................................................................................................................................317
4.2.2 MSDP Packets......................................................................................................................................................... 319
4.2.3 Process of Setting Up MSDP Peer Relationships....................................................................................................321
4.2.4 Inter-domain Multicast Source Information Transmission Among Domains......................................................... 322
4.2.5 Controlling the Forwarding of SA Messages.......................................................................................................... 324
4.3 Application Scenarios for MSDP............................................................................................................................... 326
4.3.1 Multicast Between PIM-SM Domains Within an AS Using MSDP....................................................................... 326
4.3.2 Inter-AS Multicast Using MBGP and MSDP..........................................................................................................326
4.3.3 Inter-AS Multicast Using Static RPF Peers.............................................................................................................328
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. xi

4.3.4 MSDP-based Anycast RP........................................................................................................................................ 328

4.4 Summary of MSDP Configuration Tasks................................................................................................................... 330
4.5 Licensing Requirements and Limitations for MSDP................................................................................................. 330
4.6 Default Settings for MSDP.........................................................................................................................................334
4.7 Configuring Basic MSDP Functions.......................................................................................................................... 334
4.7.1 Enabling MSDP....................................................................................................................................................... 334
4.7.2 Configuring MSDP Peers........................................................................................................................................ 335
4.7.3 (Optional) Configuring Static RPF Peers................................................................................................................ 337
4.7.4 (Optional) Configuring the MSDP Mesh Group..................................................................................................... 338
4.7.5 Verifying the Basic MSDP Function Configuration................................................................................................339
4.8 Controlling SA Messages and the SA Cache............................................................................................................. 339
4.8.1 Configuring the SA Cache.......................................................................................................................................340
4.8.2 Setting Parameters of the SA Request Message...................................................................................................... 340
4.8.3 Configuring the Content of an SA Message............................................................................................................ 341
4.8.4 Configuring the Rule for Filtering SA Messages.................................................................................................... 342
4.8.5 Verifying the Configuration of Parameters for SA Messages and SA Caching...................................................... 343
4.9 Configuring MSDP Anycast RP.................................................................................................................................343
4.9.1 Configuring an RP................................................................................................................................................... 344
4.9.2 Configuring MSDP Peer Connections.....................................................................................................................345
4.9.3 Configuring the Source RP Address of the SA Message........................................................................................ 345
4.9.4 Verifying the MSDP Anycast RP Configuration..................................................................................................... 346
4.10 Maintaining MSDP...................................................................................................................................................346
4.10.1 Clearing Statistics on MSDP Peers....................................................................................................................... 346
4.10.2 Clearing (S, G) Information in the SA Cache....................................................................................................... 347
4.10.3 Monitoring the MSDP Running Status..................................................................................................................347
4.11 Configuration Examples for MSDP..........................................................................................................................348
4.11.1 Example for Configuring PIM-SM Inter-domain Multicast Using MSDP........................................................... 348
4.11.2 Example for Configuring Inter-AS Multicast Using Static RPF Peers................................................................. 357
4.11.3 Example for Configuring Anycast RP Using MSDP.............................................................................................365
4.11.4 Example for Configuring SA Message Filtering................................................................................................... 372
4.12 Troubleshooting MSDP............................................................................................................................................ 380
4.12.1 An MSDP Peer Is Always in Down State............................................................................................................. 380
4.12.2 There Is No (S, G) Entry in the SA Cache............................................................................................................ 381
4.12.3 RPs Fail to Exchange Registration Information with Each Other.........................................................................381
5 IPv4 Multicast Route Management Configuration.............................................................383

5.1 Overview of IPv4 Multicast Route Management....................................................................................................... 383
5.2 Understanding IPv4 Multicast Route Management....................................................................................................384
5.2.1 Multicast Routing and Forwarding..........................................................................................................................384
5.2.2 RPF Check............................................................................................................................................................... 388
5.2.3 Multicast Static Route............................................................................................................................................. 391
5.2.4 Multicast Load Splitting.......................................................................................................................................... 392
5.2.5 Multicast NSR......................................................................................................................................................... 396
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. xii

5.3 Summary of IPv4 Multicast Route Management Configuration Tasks......................................................................397

5.4 Licensing Requirements and Limitations for IPv4 Multicast Route Management.................................................... 397
5.5 Default Settings for IPv4 Multicast Route Management............................................................................................400
5.6 Configuring RPF Check Policies................................................................................................................................401
5.6.1 Configuring a Multicast Static Route...................................................................................................................... 401
5.6.2 Configuring Longest Match for Multicast Route Selection.................................................................................... 402
5.6.3 Configuring IPv4 Multicast Load Splitting............................................................................................................. 402
5.6.4 Verifying the RPF Check Policy Configuration...................................................................................................... 403
5.7 Configuring an IPv4 Multicast Boundary.................................................................................................................. 404
5.8 Disabling Software Forwarding for IPv4 Multicast Packets...................................................................................... 406
5.9 Maintaining IPv4 Multicast Routes............................................................................................................................ 406
5.9.1 Monitoring IPv4 Multicast Routing and Forwarding.............................................................................................. 407
5.9.2 Configuring the Maximum Number of Invalid IPv4 Multicast Protocol Packets That a Switch Can Store...........407
5.10 Configuration Examples for IPv4 Multicast Route Management............................................................................ 409
5.10.1 Example for Configuring a Multicast Static Route to Change the RPF Route..................................................... 409
5.10.2 Example for Configuring Multicast Static Routes to Connect RPF Routes..........................................................413
5.10.3 Example for Configuring IPv4 Multicast Load Splitting...................................................................................... 419
5.11 Troubleshooting IPv4 Multicast Route Management............................................................................................... 425
5.11.1 Multicast Static Route Fails to Take Effect........................................................................................................... 425
6 IGMP Snooping Configuration.............................................................................................. 426

6.1 Overview of IGMP Snooping.....................................................................................................................................426
6.2 Understanding IGMP Snooping................................................................................................................................. 427
6.2.1 IGMP Snooping....................................................................................................................................................... 427
6.2.2 IGMP Snooping SSM Mapping.............................................................................................................................. 435
6.2.3 IGMP Snooping Proxy............................................................................................................................................ 436
6.3 Application Scenarios for IGMP Snooping................................................................................................................438
6.3.1 IGMP Snooping Application................................................................................................................................... 438
6.4 Summary of IGMP Snooping Configuration Tasks....................................................................................................439
6.5 Licensing Requirements and Limitations for IGMP Snooping.................................................................................. 441
6.6 Default Settings for IGMP Snooping......................................................................................................................... 444
6.7 Configuring Basic IGMP Snooping Functions...........................................................................................................445
6.7.1 Enabling IGMP Snooping....................................................................................................................................... 445
6.7.2 Configuring the IGMP Snooping Version............................................................................................................... 446
6.7.3 (Optional) Configuring a Static Router Port............................................................................................................448
6.7.4 (Optional) Configuring a Static Member Port......................................................................................................... 449
6.7.5 (Optional) Configuring an IGMP Snooping Querier...............................................................................................450
6.7.6 (Optional) Suppressing Report and Leave Messages.............................................................................................. 454
6.7.7 (Optional) Configuring the IPv4 Router-Alert Option............................................................................................ 455
6.7.8 (Optional) Disabling Users from Dynamically Joining Multicast Groups..............................................................456
6.7.9 Verifying the Basic IGMP Snooping Function Configuration................................................................................ 456
6.8 Configuring IGMP Snooping Proxy...........................................................................................................................457
6.9 Configuring an IGMP Snooping Policy..................................................................................................................... 459
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. xiii

6.9.1 Configuring a Multicast Group Policy.................................................................................................................... 459

6.9.2 Filtering Multicast Data on an Interface..................................................................................................................460
6.9.3 Dropping Unknown Multicast Flows...................................................................................................................... 461
6.9.4 Configuring the Function of Checking the Mappings Between Destination MAC Addresses and Destination IP
Addresses of Multicast Packets........................................................................................................................................ 461
6.9.5 Configuring a Policy to Filter IGMP Report/Leave Messages................................................................................463
6.9.6 Configuring a Policy to Filter IGMP Query Messages........................................................................................... 463
6.9.7 Configuring the Multicast Group Type for a VLAN............................................................................................... 464
6.9.8 Setting the Aging Time for Entries Triggered by Multicast Traffic in a VLAN..................................................... 465
6.9.9 Verifying the IGMP Snooping Policy Configuration.............................................................................................. 466
6.10 Configuring IGMP Snooping Membership Fast-Update..........................................................................................466
6.10.1 Setting the Aging Time of Group Member Ports.................................................................................................. 466
6.10.2 Setting the Aging Time of Dynamic Router Ports.................................................................................................467
6.10.3 Configuring Fast Leave for Member Ports............................................................................................................468
6.10.4 Configuring the Host Tracking Function...............................................................................................................469
6.10.5 Sending IGMP Query Messages upon Topology Changes....................................................................................470
6.10.6 Verifying the IGMP Snooping Membership Fast-Update Configuration..............................................................470
6.11 Configuring IGMP Snooping SSM Mapping........................................................................................................... 471
6.11.1 (Optional) Configuring an SSM Group Policy...................................................................................................... 471
6.11.2 Configuring IGMP Snooping SSM Mapping Functions....................................................................................... 472
6.11.3 Verifying the IGMP Snooping SSM Mapping Configuration............................................................................... 473
6.12 Maintaining IGMP Snooping................................................................................................................................... 473
6.12.1 Clearing IGMP Snooping Entries..........................................................................................................................473
6.12.2 Clearing IGMP Snooping Statistics.......................................................................................................................474
6.12.3 Monitoring the IGMP Snooping Running Status.................................................................................................. 475
6.12.4 Configuring the Maximum Number of Invalid Layer 2 Multicast Protocol Packets Allowed on a Multicast
Device............................................................................................................................................................................... 475
6.13 Configuration Examples for IGMP Snooping.......................................................................................................... 476
6.13.1 Example for Configuring IGMP Snooping........................................................................................................... 476
6.13.2 Example for Configuring IPv4 Layer 2 Multicast Through Static Interfaces....................................................... 479
6.13.3 Example for Configuring an IGMP Snooping Querier......................................................................................... 483
6.13.4 Example for Configuring IGMP Snooping Proxy................................................................................................. 486
6.13.5 Example for Configuring IGMP Snooping SSM Mapping................................................................................... 489
6.14 Troubleshooting IGMP Snooping.............................................................................................................................492
6.14.1 IPv4 Layer 2 Multicast Packets Cannot Be Forwarded.........................................................................................492
6.14.2 Configured IPv4 Multicast Group Policy Takes Ineffective................................................................................. 494
7 Static Multicast MAC Address Configuration.................................................................... 495

7.1 Overview of Multicast MAC Addresses.................................................................................................................... 495
7.2 Licensing Requirements and Limitations for Static Multicast MAC Addresses........................................................496
7.3 Configuring a Static Multicast MAC Address........................................................................................................... 499
7.4 Configuration Examples for Static Multicast MAC Addresses..................................................................................500
7.4.1 Example for Configuring a Static Multicast MAC Address....................................................................................500
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. xiv

8 Multicast VLAN Replication Configuration........................................................................503

8.1 Overview of Multicast VLAN Replication................................................................................................................ 503
8.2 Understanding Multicast VLAN Replication............................................................................................................. 504
8.3 Summary of Multicast VLAN Replication Configuration Tasks............................................................................... 506
8.4 Licensing Requirements and Limitations for Multicast VLAN Replication..............................................................507
8.5 Default Settings for Multicast VLAN Replication..................................................................................................... 509
8.6 Configuring Multicast VLAN Replication Based on User VLANs........................................................................... 510
8.6.1 Configuring a User VLAN...................................................................................................................................... 510
8.6.2 Binding User VLANs to a Multicast VLAN........................................................................................................... 511
8.6.3 Adding Interfaces to VLANs...................................................................................................................................512
8.6.4 Verifying the Configuration of Multicast VLAN Replication Based on User VLANs...........................................512
8.7 Configuring Interface-based Multicast VLAN Replication....................................................................................... 512
8.7.1 Configuring a User VLAN...................................................................................................................................... 513
8.7.2 Configuring IGMP Snooping in a Multicast VLAN............................................................................................... 513
8.7.3 Binding User VLANs to a Multicast VLAN........................................................................................................... 514
8.7.4 Adding Interfaces to VLANs...................................................................................................................................514
8.7.5 Verifying the Interface-based Multicast VLAN Replication Configuration............................................................514
8.8 Configuration Examples for Multicast VLAN Replication........................................................................................515
8.8.1 Example for Configuring Multicast VLAN Replication Based on User VLANs................................................... 515
8.8.2 Example for Configuring Interface-based Multicast VLAN Replication................................................................518
8.9 Troubleshooting Multicast VLAN Replication.......................................................................................................... 520
8.9.1 User Hosts in the User VLAN Fail to Receive Multicast Data............................................................................... 520
9 Multicast Network Management Configuration.................................................................522

9.1 Overview of Multicast Network Management........................................................................................................... 522
9.2 Licensing Requirements and Limitations for Multicast Network Management........................................................ 522
9.3 Configuring Multicast Network Management Functions........................................................................................... 526
9.3.1 Enabling Multicast Network Management..............................................................................................................526
9.3.2 Enabling the Trap Function for a Specified Module............................................................................................... 526
9.3.3 (Optional) Adjusting the Interval for PIM to Send Trap Messages.........................................................................527
9.3.4 Verifying the Multicast Network Management Function Configuration.................................................................528
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. xv

Configuration Guide - IP Multicast 1 IP Multicast Basics
1 IP Multicast Basics
This chapter describes fundamentals of IP multicast that you need to learn before configuring
IP multicast features.
IP multicast enables point-to-multipoint data transmission. A multicast source sends only one
copy of data, which is copied and distributed on network nodes as far from the multicast
source as possible. The multicast data is sent only to the receivers that have requested the
data.
In this chapter, the word "router" and the router icon used in figures refer to a conventional router or a
Layer 3 switch.
If multicast services need to be configured in a super virtual fabric (SVF) system, make an appropriate
multicast service plan to ensure that the number of multicast entries in the SVF will not exceed the
specifications of the leaf switches. For the number of multicast entries supported by different leaf
switches, see the feature list of the products.
1.1 Overview of IP Multicast

1.2 Understanding IP Multicast
1.3 Application Scenarios for IP Multicast
1.1 Overview of IP Multicast
Definition
In IP multicast transmission, packets are transmitted from a source to a group of receivers.
Unlike unicast and broadcast transmission, IP multicast transmission saves network
bandwidth and reduces loads on a network by allowing network nodes to replicate
information as needed. IP multicast is widely used in IPTV, real-time data transmission, and
multimedia conferencing services.
Purpose
Traditional IP communication supports two transmission modes: unicast and broadcast.
l In unicast transmission, a source sends an independent data packet to each host that has
requested the data.
Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. 1

l In broadcast transmission, a source sends data to all the hosts on the local network
segment, regardless of whether the hosts have requested the data.
To transmit data to multiple, but not all, destination hosts, a source host broadcasts the data to
all receivers or sends multiple copies of data to the destination hosts one by one, as shown in
Figure 1-1.
Figure 1-1 Point-to-multipoint data transmission in unicast and broadcast modes
Unicast transmission
Receiver
IP network
RouterA RouterD HostA
Source RouterB RouterE

HostB
RouterC RouterF
HostC
Receiver
Packets for HostA
Packets for HostC
Broadcast transmission
Receiver
A network segment
SwitchA SwitchD HostA
SwitchB SwitchE
Source HostB
HostC
SwitchC SwitchF
Receiver
Packets for all hosts

l In unicast mode, the amount of data transmitted on the network is proportional to the
number of users that have requested the data. If a large number of users require the same
data, the source host must send many copies of the data to these users, consuming high
bandwidth on the source host and network. Therefore, unicast 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 have requested the data. This threatens information security and may cause
broadcast storms on the network segment. Therefore, broadcast is not suitable for data
transmission from a source to specific destinations. It also wastes network bandwidth.
In 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 have requested the data (HostA and
HostC) can receive the same copy of the data. HostB will not receive the data.
Figure 1-2 Point-to-multipoint data transmission in multicast mode
Multicast transmission
Receiver
IP network

HostB
RouterC RouterF
HostC
Packets for the multicast group Receiver
Multicast has the following advantages over unicast and broadcast:

l Compared with unicast, multicast starts to copy data and distribute data copies on a
network node as far away from the source as possible. Therefore, the amount of data and
network resource consumption will not increase significantly when the number of
receivers increases.
l Compared with broadcast, multicast transmits data only to the receivers that have
requested the data. This conserves network resources and enhances data transmission
security.
Multicast can be used in any point-to-multipoint data transmission scenarios, including:
l Multimedia and streaming media applications
l Remote training and collaboration

l Data warehouse and financial applications (stocks and securities)
Internet service providers (ISP) use IP multicast technology to provide Internet services, such
as online live broadcasting, web TV, online education, telemedicine, web radio, and video/
audio conferencing.
1.2 Understanding IP Multicast
1.2.1 Multicast Concept
Multicast transmits data from one source to multiple receivers. Figure 1-3 shows the
multicast transmission model. HostA and HostC are interested in information sent from
Source and request the information. The data sent from Source is received only by HostA and
HostC.
Figure 1-3 Multicast transmission
Receiver
IP network

HostB
RouterC RouterF
HostC
Multicast packets Receiver
Entities in an IP multicast model are:
l Multicast group: a group of receivers identified by a multicast IP address. User hosts (or
other receiver devices) that have joined a multicast group become members of the group
and can identify and receive the IP packets destined for the multicast group address.
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 send data to a multicast group simultaneously. Generally,
a multicast source does not need to join a multicast group.
l Multicast group member: a host that has joined a multicast group. HostA and HostC in
Figure 1-3 are multicast group members. Memberships of a multicast group change

dynamically. Hosts can join or leave a multicast group at any time. Members of a
multicast group can be located anywhere on a network.
l Multicast router: a router or Layer 3 switch that supports IP multicast. The routers in
Figure 1-3 are multicast routers. They provide multicast routing functions, and those
connected to user network segments also provide multicast member management
functions.
Table 1-1 provides an analogy to explain the concept of IP multicast.
Table 1-1 Analogy between TV broadcasting and multicast transmission
Sequence TV Broadcasting Multicast Transmission
1 A television station sends A multicast source sends

data to its channel. data to a multicast group.
2 Some audience members Receivers join the multicast

turn on their TV sets and group.
select this channel.
3 TV sets play this channel. Member hosts receive data

sent to the multicast group.
4 Audience members switch Member hosts dynamically

to other channels or turn join or leave multicast
on/off their TV sets. groups.
1.2.2 Multicast Service Models
Multicast service models differ for receiver hosts but do not affect multicast sources. A
multicast source sends multicast packets by using its own IP address as the source IP address
and a group address as the destination IP address. There are two multicast models: Any-
source multicast (ASM) and source-specific multicast (SSM). The two models use multicast
group addresses in different ranges.
ASM Model
The ASM model distributes multicast data based on group addresses. A group address
identifies a collection of network services. Multicast packets sent from any source to this
address obtain the same services. After joining a group, a host can receive multicast data sent
from any source with this group address as the destination address.
For security purposes, multicast source filter policies can be configured on routers to permit
or deny packets from specific multicast sources. This filters data sent to receiver hosts.
In the ASM model, each group address must be unique on the entire multicast network. An
ASM group can only be used by a single application at a time. If two applications use the
same ASM group, receiver hosts of the two applications receive traffic from both application
sources. In this case, the network will be congested and the receiver hosts cannot function
normally.

SSM Model
The SSM model provides service for data flows from specific sources to a specific group.
Receiver hosts can specify the sources 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 sources.
The SSM model does not require globally unique group addresses, but each group address
must be unique to a multicast source. Different applications on a source must use different
SSM groups. Different applications on different sources can reuse SSM group addresses
because each source-group pair has an (S, G) entry. This model saves multicast group
addresses without congesting the network.
1.2.3 Multicast Addresses
To enable multicast sources and group members to communicate, the network must provide
network-layer multicast services using multicast IP addresses. Additionally, to enable
multicast data to be correctly transmitted on the local physical network, the network must
provide link-layer multicast services using multicast MAC addresses. The destination address
of a multicast data packet is a group with unknown members but not a specific receiver.
Therefore, multicast IP addresses must be mapped to multicast MAC addresses.
IPv4 Multicast Addresses

The Internet Assigned Numbers Authority (IANA) allocates Class D addresses for IPv4
multicast. An IPv4 address is 32 bits long, and the first four bits of a Class D IP address are
1110. Therefore, multicast IP addresses range from 224.0.0.0 to 239.255.255.255. Table 1-2
describes IPv4 multicast addresses.
Table 1-2 Range and description of IPv4 multicast addresses
Class D Address Range Description
224.0.0.0-224.0.0.255 Permanent multicast group addresses that are reserved

by the IANA for routing protocols. The addresses
identify a group of network devices and are not used
for multicast forwarding. Table 1-3 lists the
permanent multicast group addresses.
224.0.1.0-231.255.255.255 ASM group addresses that are valid on the entire

233.0.0.0-238.255.255.255 network.
NOTE
Among the ASM group addresses, 224.0.1.39 and 224.0.1.40
are reserved address, and you are not suggested to use them.
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 that are valid only

in the local administrative domain. Different
administrative domains can use the same
administrative multicast addresses.

Table 1-3 List of permanent multicast group addresses

Permanent Multicast Group Description
Addresses
224.0.0.0 Unassigned
224.0.0.1 All the hosts and routers on a network segment

(similar to a broadcast address)
224.0.0.2 All multicast routers
224.0.0.3 Unassigned
224.0.0.4 Distance Vector Multicast Routing Protocol (DVMRP)

routers
224.0.0.5 Open Shortest Path First (OSPF) routers
224.0.0.6 OSPF designated routers (DRs)
224.0.0.7 Shared tree (ST) routers
224.0.0.8 ST hosts
224.0.0.9 Routing Information Protocol version 2 (RIP-2)

routers
224.0.0.11 Mobile agents
224.0.0.12 Dynamic Host Configuration Protocol (DHCP) servers

or proxy agents
224.0.0.13 All Protocol Independent Multicast (PIM) routers
224.0.0.14 Resource Reservation Protocol (RSVP) encapsulation
224.0.0.15 Core-based tree (CBT) routers
224.0.0.16 Specified Subnetwork Bandwidth Management (SBM)

device
224.0.0.17 All SBM devices
224.0.0.18 Virtual Router Redundancy Protocol (VRRP)
224.0.0.22 IGMPv3 routers
224.0.0.19-224.0.0.21 Unassigned
224.0.0.23-224.0.0.255
IPv6 Multicast Addresses

An IPv6 address is 128 bits long. The IPv6 multicast address format is shown in Figure 1-4.

Figure 1-4 IPv6 multicast address format
0 7 11 15 31
FF Flags Scope
Group ID (112bits)
An IPv6 multicast address has a Group ID field to identify a multicast group.

l FF: The leftmost eight bits are 11111111, indicating that the address is a multicast
address. All IPv6 multicast addresses start with FF.
l Flags: This field is 4 bits long and identifies the state of a multicast address.
Table 1-4 Description of flag values

Value Description
0 Permanent multicast group addresses that

are reserved by the IANA
1 ASM group addresses
2 ASM group addresses
3 SSM group addresses
Others Unassigned
l Scope: This field is 4 bits long and identifies the scope of a multicast group, for example,
whether a multicast group covers nodes in the same network, same site, same
organization or any node in the global address space.
Table 1-5 Description of Scope field values

Value Description
0, 3, F Reserved
1 Node/Interface-local scope
2 Link-local scope
4 Admin-Local scope
5 Site-local scope
8 Organization-local scope
E Global scope
Others Unassigned

l Group ID: This field is 112 bits long and identifies a unique multicast group in the range
specified by the Scope field. The Group ID can be permanently or temporarily assigned,
depending on the value of the T flag in the Flags field.
Table 1-6 describes the IPv6 multicast address ranges.
Table 1-6 Range and description of IPv6 multicast addresses

Range Description
FF0x::/32 Reserved group addresses (see Table 1-7).
FF1x::/32 (x is not 1 or 2) ASM group addresses that are valid on the entire
FF2x::/32 (x is not 1 or 2) network.
FF3x::/32 (x is not 1 or 2) Default SSM group address range. Addresses in this

range are valid on the entire network.
Table 1-7 Commonly used IPv6 multicast addresses

Range IPv6 Multicast Addresses Description
Node/Interface- FF01::1 All node or interface addresses

local scope
FF01::2 All router addresses
Link-local scope FF02::1 All node addresses
FF02::2 All router addresses
FF02::3 Unassigned addresses
FF02::4 DVMRP routers
FF02::5 OSPF IGP routers
FF02::6 OSPF IGP DRs
FF02::7 ST routers
FF02::8 ST hosts
FF02::9 RIP routers
FF02::A EIGRP routers
FF02::B Mobile agents
FF02::D All PIM routers
FF02::E RSVP encapsulation
FF02::1:1 Link name
FF02::1:2 All DHCP proxy agents

Range IPv6 Multicast Addresses Description
FF02::1:FFXX:XXXX Solicited-node addresses (XX:XXXX

indicates the last 24 bits of a node
IPv6 address)
Site-local scope FF05::2 All router addresses
FF05::1:3 All DHCP servers
FF05::1:4 All DHCP relay agents
FF05::1:1000-FF05::1:13FF Service location
IPv4 Multicast MAC Addresses

When unicast IPv4 packets are transmitted on an Ethernet network, the packets use MAC
addresses of receivers 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, the 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 1-5. Multicast MAC address 01-00-5e-00-01-01 is
mapped to multicast IP address 224.0.1.1.
Figure 1-5 Mapping between an IPv4 multicast address and an IPv4 multicast MAC address
5 bits information loss
XXXX X
32-bit IP address 1110 XXXX X XXXXXXX XXXXXXXX XXXXXXXX
...... 23 bits ......

mapping
48-bit MAC address

00000001 00000000 01011110 0 XXXXXXX XXXXXXXX XXXXXXXX
25 bits MAC address prefix
The first four bits of an IPv4 multicast address are fixed as 1110, mapping the leftmost 25 bits
of a multicast MAC address. Among the last 28 bits, only 23 bits are mapped to a MAC
address, and 5 bits are lost. As a result, 32 multicast IP addresses are mapped to one MAC
address. For example, multicast IP 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. Address conflicts
must be considered in address assignment.

IPv6 Multicast MAC Addresses

In an IPv6 multicast MAC address, the leftmost 16 bits are 0x3333, and the rightmost 32 bits
are mapped to the rightmost 32 bits of an IPv6 multicast address. Figure 1-6 shows the
mapping between IPv6 multicast address FF01::1111:1 and an IPv6 multicast MAC address.
128-bit IPv6 address
FF01 0000 0000 0000 0000 0000 1111 0001
... ...
32 bits
mapping
48-bit MAC address 3333 1111 0001
More IPv6 multicast addresses are mapped to the same multicast MAC address.
1.2.4 IPv4 Multicast Protocols

In IP multicast transmission, the sender only needs to send data to a specified destination
address and does not need to know the locations of receivers. It is the responsibility of
network devices to forward data from the sender to the receivers. Multicast devices on the
network must collect information about senders and duplicate and forward multicast data
along the correct path. During multicast development, a complete suite of protocols are
introduced.
Table 1-8 describes multicast protocols on an IPv4 network.

Table 1-8 IPv4 multicast protocols

Protocol Function Remarks
Internet Group Management IGMP manages IPv4 IGMP has three versions:
Protocol (IGMP) multicast group members IGMPv1, IGMPv2, and
and runs on the end of a IGMPv3.
multicast network (network All these versions support
segments where Layer 3 the any-source multicast
multicast devices connect to (ASM) model. IGMPv3 can
user hosts). Hosts use the be independently used in the
IGMP protocol to join or SSM model, whereas
leave multicast groups. IGMPv1 and IGMPv2 use
Layer 3 multicast devices source-specific multicast
use the IGMP protocol to (SSM) mapping.
manage and maintain group
memberships. IGMP can
interact with upper-layer
multicast routing protocols.
Protocol Independent PIM runs on an IPv4 The PIM-DM model does

Multicast (PIM) network and sends multicast not need to differentiate
data to multicast devices between ASM and SSM.
connected to group The PIM-SM model
members interested in the differentiates between ASM
data. and SSM based on multicast
The CloudEngine 6800 addresses in data and
series switches support protocol packets.
Protocol Independent l If multicast addresses of
Multicast - Sparse Mode packets are in the SSM
(PIM-SM), Bidirectional group address range,
Protocol Independent PIM-SM uses the SSM
Multicast (Bidirectional model to provide
PIM) and Protocol multicast services. The
Independent Multicast - PIM-SSM model is
Dense Mode (PIM-DM). efficient and simplifies
PIM-DM applies to small- the multicast address
scale networks with densely allocation process. It is
distributed group members, applicable when a group
and PIM-SM applies to the has only one specific
large network where source.
receivers are widely
distributed, and l If multicast addresses of
Bidirectional PIM applies to packets are in the ASM
the network with multiple group address range,
multicast sources. PIM-SM uses the ASM
model to provide
multicast services.

Protocol Function Remarks
Multicast Source Discovery MSDP is an inter-domain MSDP is required only

Protocol (MSDP) multicast protocol that when the ASM model is
implements multicast used.
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.
Multiprotocol Border MBGP enables multicast -

Gateway Protocol (MBGP) data to be transmitted
between multicast sources
and receivers in different
autonomous systems (ASs).
IGMP snooping and IGMP IGMP snooping enables a IGMP snooping is an

snooping proxy switch to create and extension of IGMP on Layer
maintain a Layer 2 multicast 2 network devices. You can
forwarding table by specify the IGMP snooping
listening to IGMP packets version on a switch to
exchanged between the enable the switch to process
upstream Layer 3 device and IGMP packets of specific
user hosts. The switch versions.
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 the switch to act in
place of 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 local
switch.
1.3 Application Scenarios for IP Multicast

1.3.1 Multicast Deployment on an IPv4 Network

This section describes typical multicast service scenarios on an IPv4 network and applications
of multicast protocols. Configure multicast services based on the actual situations and service
requirements on your network. This section provides only deployment of basic multicast
services.
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-7 shows this type of multicast service deployment.
Figure 1-7 Multicast service deployment within a PIM domain

Source
RouterA
PIM PIM
IP network
RouterB RouterC
IGMP IGMP
IGMP Snooping /
SwitchA IGMP Snooping
Proxy
HostB
LAN Receiver
HostA
Receiver

Table 1-9 Protocols used for multicast within a PIM domain

Protocol Application Position Purpose
PIM (mandatory) PIM must be configured on all PIM sends multicast data from
interfaces of Layer 3 multicast the multicast source to RouterB
devices in the PIM domain, and RouterC, which are
including all interfaces of connected to multicast
RouterA, RouterB, and receivers.
RouterC.
For the configuration
procedure, see 3 IPv4 PIM
Configuration.
IGMP (mandatory) IGMP must be configured on IGMP allows receiver hosts to

user-side interfaces of Layer 3 join or leave multicast groups,
multicast devices RouterB and and allows RouterB and
RouterC. RouterC to maintain and
For the configuration manage multicast memberships.
procedure, see 2 IGMP
Configuration.
IGMP snooping and IGMP snooping and IGMP IGMP snooping listens to
IGMP snooping snooping proxy must be IGMP packets exchanged
proxy (optional) configured in VLANs on between RouterB and HostA to
SwitchA, a device between a create and maintain a Layer 2
Layer 3 multicast device and multicast forwarding table. In
user hosts. this manner, SwitchA can
For the configuration control forwarding of multicast
procedure, see 6 IGMP data packets on the Layer 2
Snooping Configuration. network.
IGMP snooping proxy allows
SwitchA to act in place of
RouterB to send IGMP Query
messages and in place of 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 the
management of multicast resources, including groups, multicast sources, and group members.
To enable the PIM-SM domains to exchange multicast data, MSDP needs to be deployed
between them, as shown in Figure 1-8.
MSDP is not required when PIM-SM uses the SSM model.

Figure 1-8 Multicast service deployment between PIM-SM domains
PIM-SM 1 PIM-SM 2 Source2
PIM
IP network IP network
RP PIM
RouterB RouterC RouterE
MSDP
PIM RP RouterD
PIM
PIM
RouterF
RouterA IGMP Snooping / IGMP
IGMP Snooping
Proxy SwitchA
LAN
Source1 LAN
Host (Receiver)
Table 1-10 Multicast protocols used for multicast between PIM-SM domains
PIM-SM (mandatory) PIM-SM must be configured on PIM-SM sends multicast data

all interfaces of Layer 3 from multicast sources Source1
multicast devices in the PIM- and Source2 to RouterF, which
SM domains, including all is connected to multicast
interfaces of Routers A to F. receivers. After receiver hosts
For the configuration join a multicast group,
procedure, see 3.8 Configuring multicast data is forwarded to
IPv4 PIM-SM. the receiver hosts through
rendezvous points (RPs) in the
PIM-SM domains.

multicast device RouterF in the and allows RouterF to maintain
PIM-SM domains. and manage multicast
For the configuration memberships.
Configuration.

MSDP (mandatory) MSDP must be configured on MSDP transmits multicast data

the RP in each PIM-SM between PIM-SM1 and PIM-
domain, that is, RouterC and SM2. Host in PIM-SM2 can
RouterD. receive data from Source1.
procedure, see 4 MSDP
Configuration.
IGMP snooping and IGMP snooping and IGMP IGMP snooping listens to
IGMP snooping snooping proxy must be IGMP messages exchanged
proxy (optional) configured in VLANs on between RouterF and hosts to
SwitchA, a device between a create and maintain a Layer 2
Layer 3 multicast device and multicast forwarding table. In
user hosts. this manner, SwitchA can
For the configuration control forwarding of multicast
procedure, see 6 IGMP data packets on the Layer 2
Snooping Configuration. network.
IGMP snooping proxy allows
SwitchA to act in place of
RouterF to send IGMP Query
messages and in place of 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 autonomous systems (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-9 shows the inter-AS multicast service deployment.
Before configuring MBGP between ASs, configure BGP between the ASs.

Figure 1-9 Inter-AS multicast service deployment
AS 100 HostA (Receiver)
IGMP
RP PIM-SM 1
PIM
RouterA
RouterB
MSDP
AS 200 MBGP
Source2
Source1
RouterG
RouterC PIM PIM
RP RP
PIM-SM 2 MSDP
PIM-SM 3
RouterD RouterH
PIM PIM IGMP
RouterF
RouterE HostB (Receiver)
Table 1-11 Multicast protocols used for inter-AS multicast

PIM-SM (mandatory) PIM-SM must be configured on PIM-SM sends multicast data

all interfaces of Layer 3 from multicast sources Source1
multicast devices in the PIM- and Source2 to RouterB and
SM domains, including all RouterH, which are connected
interfaces of Routers A to H. to multicast receivers. After
For the configuration receiver hosts join a multicast
procedure, see 3.8 Configuring group, multicast data is
IPv4 PIM-SM. forwarded to the receiver hosts
through RPs in the PIM-SM
domains.


multicast devices RouterB and and allows RouterB and
RouterH in the PIM-SM RouterH to maintain and
domains. manage multicast memberships.
Configuration.
MBGP (mandatory) MBGP must be configured on MBGP sends multicast data

RouterA and RouterF located at from multicast sources Source1
the AS borders. and Source2 to receivers in
For the configuration another AS based on an
procedure, see Configuring independent multicast routing
MP-BGP. table.
MSDP (mandatory) MSDP must be configured on MSDP transmits multicast data

the RP in each PIM-SM: among PIM-SM1, PIM-SM2,
RouterA, RouterD, and and PIM-SM3.
RouterF.
procedure, see 4 MSDP
Configuration.

Configuration Guide - IP Multicast 2 IGMP Configuration
2 IGMP Configuration
You can manage multicast group members by configuring Internet Group Management
Protocol (IGMP) on multicast device interfaces connected to user networks.
In this chapter, the word "router" and the router icon used in figures refer to a conventional router or a
Layer 3 switch.
2.1 Overview of IGMP

2.2 Understanding IGMP
2.3 Application Scenarios for IGMP
2.4 Summary of IGMP Configuration Tasks
2.5 Licensing Requirements and Limitations for IGMP
2.6 Default Settings for IGMP
2.7 Configuring Basic IGMP Functions
2.8 Optimizing IGMP Performance
2.9 Configuring IGMP SSM Mapping
2.10 Maintaining IGMP
2.11 Configuration Examples for IGMP
2.12 Troubleshooting IGMP
2.1 Overview of IGMP

Definition
The Internet Group Management Protocol (IGMP) is a part of the TCP/IP protocol suite used
to manage IPv4 multicast group membership. IGMP sets up and maintains membership
between receiver hosts and directly-connected multicast routers by exchanging IGMP
messages between them. IGMP messages are encapsulated in IP packets.

Purpose
IP multicast routing transmits packets from a source to a group of receivers. In the multicast
communications model, the sender only needs to send data to a specified destination address
and does not need to know the exact locations of the receivers. To forward multicast data
packets to the receivers, the multicast router connected to the network segment of receiver
hosts must know which receiver hosts are present on the network segment and ensure that
these hosts have joined the specific group. IGMP implements this by setting up and
maintaining membership between receiver hosts and directly connected multicast routers.
Figure 2-1 indicates how the IGMP protocol is deployed on a multicast network.
Figure 2-1 IGMP deployment on a multicast network
PIM network
RouterA RouterB
LAN
HostA HostB HostC
IGMP-enabled interface
2.2 Understanding IGMP
2.2.1 IGMP Versions
Currently, there are three versions of IGMP: IGMPv1, IGMPv2 and IGMPv3.
IGMPv1 defines the group membership query and report processes. IGMPv2 extends
IGMPv1 by adding the querier election and member leave mechanisms. IGMPv3 extends
IGMPv2 by allowing hosts to specify the multicast sources they do or do not want to receive
data from. IGMP versions are backward compatible. This means that a multicast router
running a later IGMP version can identify IGMP messages sent from hosts running an earlier
IGMP version, even though IGMP messages in different versions are sent using different
formats.
All IGMP versions support the any-source multicast (ASM) model. IGMPv3 can be directly
applied to the source-specific multicast (SSM) model. IGMPv1 and IGMPv2, however, can be
applied to the SSM model only when IGMP SSM mapping is configured. For details about
the ASM and SSM models, see Multicast Service Models.
Table 2-1 compares the three IGMP versions.

Table 2-1 Comparison of IGMP versions
Item IGMPv1 IGMPv2 IGMPv3
Querier election Through Protocol Through Through

Independent competition among competition among
Multicast (PIM) multicast routers on multicast routers on
a local network a local network
segment segment
General Query Supported Supported Supported

message
Report message Supported Supported Supported
Group-Specific Not supported Supported Supported

Query message
Leave message Not supported Supported No specific Leave

message is defined.
Instead, group
members send a
specified type of
Report message to
notify multicast
routers that they are
leaving a group.
Group-and-Source- Not supported Not supported Supported

Specific Query
message
Specifying multicast Not supported Not supported Supported

source in Report
messages
Protocol message IGMPv1 IGMPv1, IGMPv2 IGMPv1, IGMPv2,

versions supported IGMPv3
ASM model Supported Supported Supported
SSM model IGMP SSM IGMP SSM Supported

mapping required mapping required
2.2.2 IGMPv1 Fundamentals
IGMPv1 Messages
IGMPv1 defines two types of message:
l General Query: A querier sends General Query messages to all hosts and routers on the
local network segment to discover which multicast groups have members on the network
segment.

l Report: Hosts send Report messages to multicast routers to request to join a multicast
group or respond to General Query messages.
Figure 2-2 shows the IGMPv1 message format, and Table 2-2 describes the message fields.
Figure 2-2 IGMPv1 message format
0 3 7 15 31
Version Type Unused Checksum
Group Address
Table 2-2 Fields in an IGMPv1 message
Field Description
Version In IGMPv1 messages, this field is set to 1.
Type The two message type options are:

l 0x1: General Query message
l 0x2: Report message
Unused In IGMPv1 messages, this field is set to 0 by the sender and

is ignored by the receiver.
Checksum The checksum is 16 bits long. It is the one's complement of

the one's complement sum of the whole IGMP message (the
entire IP payload). When computing the checksum, a device
initially sets the checksum field to 0. The sender computes
the checksum and inserts it into this field. The receiver
verifies the checksum before processing the message.
Group Address In a General Query message, this field is set to 0. In a

Membership Report message, this field is set to the address
of the group that the member requests to join.
How IGMPv1 Works

IGMPv1 uses a query-report mechanism to manage multicast groups. When there are multiple
multicast routers on a network segment, all multicast routers can receive Membership Report
messages from hosts. Therefore, only one multicast router needs to send Query messages to
the network segment. The router selected to send Query messages is regarded as the IGMP
querier. In IGMPv1 implementation, a unique Assert winner or designated router (DR) is
selected by Protocol Independent Multicast (PIM) as the querier. The querier is the only
device that sends Host Membership Query messages on the local network segment.
For details about Assert and DR election, see 3.2.3 PIM-SM (ASM Model).
Figure 2-3 shows a network running IGMPv1. RouterA and RouterB connect to a network
segment with three receivers: HostA, HostB, and HostC. RouterA is the IGMP querier on the
network segment. HostA and HostB want to receive data sent to group G1, and HostC wants
to receive data sent to group G2.

Figure 2-3 Multicast network
Source
PIM network
RouterA RouterB
IGMP querier
LAN
HostA HostB HostC

(G1) (G1) (G2)
IGMPv1 involves three mechanisms: general query and report mechanism, join
mechanism, and leave mechanism.
General query and report mechanism

By sending General Query messages and receiving Report messages, an IGMP querier knows
which groups have members on the local network segment.
Figure 2-4 IGMPv1 general query and report process

HostB RouterA HostA
(G1) IGMP querier (G1)
General General
Query Query
1
Report for G1 Report for G1
2
Multicast data Multicast data
3 for G1 for G1
Figure 2-4 shows the general query and report process:

1. The IGMP querier sends a General Query message, with destination address 224.0.0.1
(indicating all hosts and routers on the network segment). All group members start a
timer when they receive the General Query message.
The IGMP querier sends General Query messages at intervals. The interval is
configurable and defaults to 60 seconds. HostA and HostB are members of G1 and they
start a timer for G1 (Timer-G1). The timer length is a random value between 0 and the
maximum response time (10 seconds by default).
2. The host whose timer expires first sends a Report message for the group.
In this example, the Timer-G1 on HostA expires first, and HostA sends a Report message
with the destination address G1. When HostB receives the Report message sent by

HostA, it stops Timer-G1 and does not send a Report message for G1. This mechanism
reduces the number of Report messages transmitted on the network segment, lowering
loads on multicast routers.
3. After the IGMP querier receives the Report message from HostA, it knows that group
G1 has members on the local network segment. The IGMP querier uses the multicast
routing protocol to create a (*, G1) entry, in which * stands for any multicast source.
Once the IGMP querier receives data sent to G1, it forwards the data to this network
segment.
Join mechanism
Figure 2-5 IGMPv1 join process

RouterA HostC
IGMP querier (G2)
Report for G2
1
Multicast
2 data for G2
Figure 2-5 shows how HostC joins group G2:

1. HostC sends a Report message for G2 without waiting for a General Query message.
2. After receiving the Report message, the IGMP querier knows that a member of G2 has
connected to the local network segment, and creates a (*, G2) entry. Once the IGMP
querier receives data sent to G2, it forwards the data to this network segment.
Leave mechanism
IGMPv1 does not define a Leave message. After a host leaves a group, it no longer responds
to General Query messages. On the network in Figure 2-3:
l If HostA leaves group G1
When HostA receives General Query messages from the IGMP querier, it does not send
a Report message for G1. Group G1 has another member HostB on the network segment,
which still sends Report messages for G1 in response to General Query messages.
Therefore, the IGMP querier is unaware HostA has left the group.
l If HostC leaves group G2
When HostC receives General Query messages from the IGMP querier, it does not send
a Report message for G2. Because G2 has no other members on this network segment,
the IGMP querier no longer receives Report messages for G2. After a certain period (130
seconds by default), the IGMP querier deletes the (*, G2) entry.
2.2.3 Changes in IGMPv2

IGMPv2 works similarly to IGMPv1. The most significant difference between the two
versions lies in the leave mechanism. When an IGMPv2 host leaves a group, it sends a Leave
message to the IGMP querier. When the IGMP querier receives the Leave message, it sends a
Group-Specific Query message to check whether the group has other members. If the IGMP

querier does not receive any Report messages for the group within a specified period, it no
longer maintains membership of the group. IGMPv2 enables an IGMP querier to know the
groups that have no members on a local network segment and update group membership
quickly. This leave mechanism reduces redundant multicast traffic on the network.
IGMPv2 Messages
IGMPv2 differs from IGMPv1 in the following ways:
l In addition to General Query and Report messages IGMPv2 defines two new message
types:
– Leave message: sent by a host to notify the querier on the local network segment
that it has left a group.
– Group-Specific Query message: sent by a querier to a specified group on the local
network segment to check whether the group has members.
l IGMPv2 adds a new field to General Query messages: Max Response Time. This field
can be configured to control hosts' response speed to Query messages.
Figure 2-6 shows the IGMPv2 message format, and Table 2-3 describes the message fields.
Figure 2-6 IGMPv2 message format

0 7 15 31
Type Max Response Time Checksum
Group Address
Table 2-3 Fields in an IGMPv2 message

Field Description
Type The four message type options are:

l 0x11: Query message. IGMPv2 Query messages include
General Query and Group-Specific Query messages.
l 0x12: IGMPv1 Report message
l 0x16: IGMPv2 Report message
l 0x17: Leave message
Max Response Time After receiving a General Query message, hosts must
respond with a Report message within the maximum
response time. This field is valid only in IGMP Query
messages.


Field Description
Group Address The group address is set differently in different types of

messages:
l In a General Query message, this field is set to 0.
l In a Group-Specific Query message, this field is set to the
address of the queried group.
l In a Report or Leave message, this field is set to the
address of the group that the host wants to join or leave.
How IGMPv2 Works

IGMPv2 introduces the querier election and leave mechanisms.
Figure 2-7 shows a multicast network running IGMPv2. RouterA and RouterB connect to a
network segment with three receivers: HostA, HostB, and HostC. HostA and HostB want to
receive data sent to group G1, and HostC wants to receive data sent to group G2.
Figure 2-7 Multicast network
Source
PIM network
RouterA RouterB
LAN
HostA HostB HostC

(G1) (G1) (G2)
The following describes the querier election and leave processes on the network in Figure
2-7.
Querier election mechanism
IGMPv2 defines an independent querier election mechanism. When multiple multicast routers
are present on a local network segment, the router with the smallest IP address is elected as
the querier.

Figure 2-8 IGMPv2 querier election process
RouterA RouterB
10.10.1.1/24 10.10.1.2/24
Host
RouterA's
Query
1
RouterA sends RouterB's
a Query as a Query
2 querier
Figure 2-8 shows how an IGMPv2 querier is elected:

1. All IGMPv2 routers (RouterA and RouterB in this example) consider themselves
queriers and send General Query messages to all hosts and routers on the shared network
segment.
When the routers receive a General Query message, they compare the source IP address
of the message with their own interface IP addresses. The router with the smallest IP
address becomes the querier, and the other routers are considered non-queriers. In this
example, RouterA has a smaller interface IP address than RouterB. Therefore, RouterA
becomes a querier, and RouterB becomes a non-querier.
2. The IGMP querier (RouterA) sends General Query messages to all hosts and other
multicast routers on the local network segment. The non-querier (RouterB) no longer
sends General Query messages.
RouterB starts the other querier present timer. If RouterB receive a Query message from
the querier before the timer expires, it resets the timer. Otherwise, it triggers a querier
election.
Leave mechanism
Figure 2-9 IGMPv2 leave process

HostA RouterA HostB
(G1) IGMP querier (G1)
Leave for G1
1 G1-Specific
G1-Specific
Query
2 Query
Report for G1
3
Figure 2-9 shows message exchanges when HostA leaves group G1:

1. HostA sends a Leave message for G1 to all multicast routers on the local network
segment. The destination address of the Leave message is 224.0.0.2.
2. When the querier receives the Leave message, it sends Group-Specific Query messages
for G1 at intervals to check whether G1 has other members on the network segment. The
query interval and count are configurable. By default, the querier sends Group-Specific
Query messages twice, at an interval of 1 second. In addition, the querier starts the group
membership timer. The timer length is the product of the group-specific query interval
and count.
3. There is another member of G1 on the network segment, HostB, which sends a Report
message for G1 immediately after receiving a Group-Specific Query message. The
querier therefore continues maintaining the membership of G1.
If G1 has no members on the network segment, the querier will not receive a Report
message for G1. When the group membership timer times out, the querier deletes the (*,
G1) entry. Thereafter, if the querier receives multicast data sent to G1, it does not
forward the data downstream.
2.2.4 Changes in IGMPv3
IGMPv3 was developed to support the source-specific multicast (SSM) model. IGMPv3
messages can contain multicast source information so that hosts can receive data sent from a
specific source to a specific group.
IGMPv3 Messages
IGMPv3 differs from IGMPv2 in the following ways:
l Unlike IGMPv2, IGMPv3 does not define a Leave message. Group members send
Report messages of a specified type to notify multicast routers that they have left a
group.
l In addition to General Query and Group-Specific Query messages, IGMPv3 defines
another Query message type: Group-and-Source-Specific Query. A querier sends a
Group-and-Source-Specific Query message to members of a specific group on a shared
network segment, to check whether the group members want data from specific sources.
A Group-and-Source-Specific Query message can carry one or more multicast source
addresses.
l A Membership Report message contains the group that a host wants to join and the
multicast sources from which the host wants to receive data. IGMPv3 supports source
filtering and defines two filter modes: INCLUDE and EXCLUDE. Group-source
mappings are represented as (G, INCLUDE, (S1, S2...)) or (G, EXCLUDE, (S1, S2...)).
INCLUDE indicates that a host only wants to receive data sent from the listed multicast
sources to group G. EXCLUD indicates that a host wants to receive data sent from all
multicast sources except the listed ones to group G. When group-source mappings
change, hosts add these changes to the Group Record fields in IGMPv3 Report messages
and send IGMPv3 Report messages to the IGMP querier on the local network segment.
l An IGMPv3 Report message can carry multiple groups, whereas an IGMPv1 or IGMPv2
Report message can carry only one group. IGMPv3 greatly reduces the number of
messages transmitted on a network.
Figure 2-10 shows the IGMPv3 Query message format, and Table 2-4 describes message
fields.

Figure 2-10 IGMPv3 Query message format

0 7 15 31
Type Max Resp Code Checksum
Group Address
Resv S QRV QQIC Number of Sources (N)
Sources Address [ 1 ]
Sources Address [ 2 ]
...
Sources Address [ N ]
Table 2-4 Fields in an IGMPv3 Query message

Field Description
Type In IGMPv3 Query messages, this field is set to 0x11.
Max Response Code Maximum response time. After receiving a General Query
message, hosts must respond with a Report message within
the maximum response time.

Group Address The group address is set differently in different Query

messages:
l In a General Query message, this field is set to 0.
l In a Group-Specific Query or Group-and-Source-Specific
Query message, this field is set to the address of the
queried group.
Resv Reserved field. This field is set to 0 by the sender and is

ignored by the receiver.
S Suppress router-side processing. When this flag is set to 1,

routers receiving the Query message suppress timer updates,
bur so not suppress the querier election or normal host-side
processing.
QRV Querier's robustness variable. A non-0 value indicates the

robustness variable of the querier. This field is set to 0 if the
robustness variable of the querier exceeds 7. When a router
receives a Query message and finds that the QRV field is not
0, the router sets its robustness variable to the value of the
QRV field. If the QRV field is 0, the router ignores this field.

Field Description
QQIC Querier's query interval code, expressed in seconds. When a

non-querier router receives a Query message and finds that
the QQIC field is not 0, the non-querier router sets its query
interval to the value of the QQIC field. If the QQIC field is 0,
the non-querier router ignores this field.
Number of Sources In a General Query or Group-Specific Query message, this

field is set to 0. In a Group-and-Source-Specific Query
message, this field is a non-zero integer. The number is
limited by the MTU of the network over which the Query
message is transmitted.
Source Address The value of this field is limited by the value of the Number
of Sources field.
Figure 2-11 shows the IGMPv3 Membership Report message format, and Table 2-5 describe
the message fields.
Figure 2-11 IGMPv3 Membership Report message format

0 7 15 31
Type Reserved Checksum
Reserved Number of Group Records (M)
Group Record [ 1 ]
Group Record [ 2 ]
...
Group Record [ M ]
Table 2-5 Fields in an IGMPv3 Membership Report message

Field Description
Type In IGMPv3 Membership Report messages, this field is set to

0x22.
Reserved This field is set to 0 by the sender and is ignored by the

receiver.

Number of Group Records Number of group records in the message.
Group Record Group information in the message. Figure 2-12 shows the
format of a group record, and Table 2-6 explains the fields in
a group record.

Figure 2-12 Group record format

0 7 15 31
Record Type Aux Data Len Number of Sources (N)
Multicast Address
Source Address [ 1 ]
Source Address [ 2 ]
...
Source Address [ N ]
Auxiliary Data

Table 2-6 Fields in a group record

Field Description
Record Type The three group record type options are:

l Current-State Record: sent by a host in response to a
Query message to report the current state. This record
type is one of the following two values:
– MODE_IS_INCLUDE: indicates that the host wants
to receive multicast data sent from the listed source
addresses to the specified multicast group address.
The Report message is invalid if the source list is
empty.
– MODE_IS_EXCLUDE: indicates that the host does
not want to receive multicast data sent from the listed
source addresses to the specified multicast group
address.
l Filter-Mode-Change Record: sent by a host when the
filter mode changes. This record type is one of the
following two values:
– CHANGE_TO_INCLUDE_MODE: indicates that the
filter mode has changed from EXCLUDE to
INCLUDE. The host wants to receive multicast data
sent from the new sources in the Source Address fields
to the specified multicast group address. If the source
list is empty, the host will leave the group.
– CHANGE_TO_EXCLUDE_MODE: indicates that the
filter mode has changed from INCLUDE to
EXCLUDE. The host rejects multicast data sent from
the new sources in the Source Address fields to the
specified multicast group address.
l Source-List-Change Record: sent by a host when the
source list changes. This record type is one of the
following two values:
– ALLOW_NEW_SOURCES: indicates that the Source
Address fields in this group record contain additional
sources from which the host wants to receive multicast
data, sent to the specified multicast group address. If
the filter mode is INCLUDE, the sources in the Source
Address fields are added to the source list. If the filter
mode is EXCLUDE, the sources in the Source
Address fields are deleted from the source list.
– BLOCK_OLD_SOURCES: indicates that the Source
Address fields in this group record contain the sources
from which the host no longer wants to receive
multicast data. If the filter mode is INCLUDE, the
sources in the Source Address fields are deleted from
the source list. If the filter mode is EXCLUDE, the
sources in the Source Address fields are added to the
source list.

Field Description
Aux Data Len Length of the Auxiliary Data field. IGMPv3 Report
messages do not contain auxiliary data, so this field is set to
0.
Number of Sources Number of source addresses in this group record.
Multicast Address Address of a multicast group.
Sources Address Address of a multicast source.
Auxiliary Data Additional information in this group record. This field is

reserved for IGMP extensions or later IGMP versions, and is
not included in IGMPv3 Report messages.
How IGMPv3 Works

IGMPv3 differs from IGMPv2 and IGMPv3 in that it allows hosts to select specific multicast
sources.
Joining a specific source and group
IGMPv3 Report messages have a destination address of 224.0.0.22, which represents all
IGMPv3-capable multicast routers on the same network segment. A Report message contains
Group Record fields, allowing hosts to specify the multicast sources from which they do or do
not want to receive data when joining a multicast group. Figure 2-13, shows two multicast
sources, S1 and S2, sending data to multicast group G. The host only wants to receive data
sent from S1 to G.
Figure 2-13 IGMPv3 source-and-group-specific multicast data flow
S1
RouterA RouterB
S2 RouterC RouterD
Host (G)
(S1, G) Multicast packets
(S2, G) Multicast packets
If IGMPv1 or IGMPv2 is running between the host and the routers, the host cannot select
multicast sources when it joins group G. The host receives data from both S1 and S2,
regardless of whether it requires the data. If IGMPv3 is running between the host and the
routers, the host can send an IGMPv3 Report (G, INCLUDE, (S1)), requesting to receive only
the data sent from S1 to G.

Group-and-Source-Specific Query
When an IGMP querier receives a Report message with Filter-Mode-Change Records or
Source-List-Change Records (such as CHANGE_TO_INCLUDE_MODE or
CHANGE_TO_EXCLUDE_MODE), it sends a Group-and-Source-Specific Query message.
If members want to receive data from any source in the source list, they send Report
messages. The IGMP querier updates the source list of the corresponding group according to
the received Report messages.
2.2.5 IGMP SSM Mapping

Source-specific multicast (SSM) requires multicast routers to know which multicast sources
hosts specify when they join a multicast group. A host running IGMPv3 can specify multicast
source addresses in IGMPv3 Report messages. However, hosts running IGMPv1 or IGMPv2
rely on the IGMP SSM mapping function to obtain the SSM service.
IGMP SSM mapping is implemented based on static SSM mapping entries. A multicast router
converts (*, G) information in IGMPv1 and IGMPv2 Report messages to (G, INCLUDE, (S1,
S2...)) information according to static SSM mapping entries to provide the SSM service for
IGMPv1 and IGMPv2 hosts.
With SSM mapping entries configured, an IGMP querier checks the group address G in each
IGMPv1 or IGMPv2 Report message received, and processes the message based on the check
result:
l If G is in the any-source multicast (ASM) group address range, the router provides the
ASM service for the host.
l If G is in the SSM group address range (232.0.0.0 to 232.255.255.255 by default):
– When the IGMP querier has no SSM mapping entry matching G, it does not provide
the SSM service and drops the Report message.
– If the IGMP querier has an SSM mapping entry matching G, it converts (*, G)
information in the Report message into (G, INCLUDE, (S1, S2...)) information and
provides the SSM service for the host.
On an SSM network shown in Figure 2-14, HostA, HostB, and HostC are running IGMPv3,
IGMPv2, and IGMPv1, respectively. HostB and HostC do not support IGMPv3. To provide
the SSM service for all the hosts, IGMP SSM mapping must be configured on the router.
Figure 2-14 SSM mapping

IGMPv3
S1: 10.10.1.1 Membership Report
S2: 10.10.2.2
HostA
IGMPv2
SSM Membership Report
network HostB
(G1: 232.1.2.2)
Router IGMPv1
IGMP querier Membership Report
S3: 10.10.3.3
HostC
S4: 10.10.4.4 (G2: 232.1.1.1)

The following table lists the SSM mapping entries configured on the router.
Group Address Multicast Source Address
232.0.0.0/8 10.10.1.1
232.1.0.0/16 10.10.2.2
232.1.0.0/16 10.10.3.3
232.1.1.0/24 10.10.4.4
When the router receives Report messages from HostB and HostC, it checks whether the
group addresses in the messages are in the SSM group address range. If so, the router
generates (S, G) entries based on the SSM mappings. If a group address is mapped to multiple
sources, the router generates multiple (S, G) entries.
The router generates an (S, G) entry based on each SSM mapping entry matching a group
address. Therefore, the router generates four (S, G) entries for 232.1.1.1, and three (S, G)
entries for 232.1.2.2.
Group Address in IGMPv1/IGMPv2 Generated Multicast Forwarding Entry

Report
232.1.1.1 (from HostC) (10.10.1.1, 232.1.1.1)

(10.10.2.2, 232.1.1.1)
(10.10.3.3, 232.1.1.1)
(10.10.4.4, 232.1.1.1)
232.1.2.2 (from HostB) (10.10.1.1, 232.1.2.2)

(10.10.2.2, 232.1.2.2)
(10.10.3.3, 232.1.2.2)
IGMP SSM mapping does not apply to IGMPv3 Report messages. To enable hosts running any IGMP
version on a network segment to obtain the SSM service, IGMPv3 must run on interfaces of multicast
routers on the network segment.
2.3 Application Scenarios for IGMP
2.3.1 Typical IGMP Application

IGMP runs between member hosts and directly connected multicast routers to manage and
maintain multicast group membership. To forward multicast data from multicast sources to
receivers, multicast routers must run Protocol Independent Multicast (PIM) to set up
forwarding paths. Figure 2-15 illustrates a typical IGMP network topology.

Figure 2-15 Typical IGMP network topology
PIM network HostA
RouterB
Source1
RouterA
RouterC
RouterE HostB
RouterD
Source2
HostC
IGMP-enabled interface
The following solutions can be used in IGMP application.
Solution Member Hosts Interfaces All Routers on the

Connected to Network
Member Hosts
Hosts dynamically Enable IGMPv1 or Enable IGMPv1 or Enable Bidir-PIM or

join multicast IGMPv2. IGMPv2. PIM-SM.
groups through
ASM.
Hosts dynamically Enable IGMPv3. Enable IGMPv3. Enable PIM-SM.

join multicast
groups through
SSM.
Hosts dynamically Enable IGMPv1 or Enable IGMPv3 and Enable PIM-SM.

join multicast IGMPv2. IGMP SSM
groups through SSM mapping, and
mapping. configure source-
group mapping.

2.4 Summary of IGMP Configuration Tasks

Table 2-7 IGMP configuration tasks
Scenario Description Task
Configure basic IGMP To configure receiver hosts 2.7 Configuring Basic

functions to join a multicast network IGMP Functions
and receive multicast data,
you must configure basic
IGMP functions on the
switch interfaces connected
to the receiver hosts.
Optimize IGMP With basic IGMP functions 2.8 Optimizing IGMP

performance configured, a multicast Performance
switch can exchange IGMP
messages with receiver
hosts using default settings.
You can optimize IGMP
performance on the switch
according to network
security and performance
requirements.
Configure IGMP SSM The source-specific 2.9 Configuring IGMP

mapping multicast (SSM) model SSM Mapping
allows IGMPv3 hosts to
specify the multicast sources
from which they want to
receive data. To allow
receiver hosts running
IGMPv1 or IGMPv2 to use
the SSM service, configure
IGMP SSM mapping on the
multicast switch.

Involved Network Elements
An IPv4 multicast network may have the following network elements:
l Multicast source: sends multicast data to receiver hosts. A video server is an example of
a multicast source.
l Device running IPv4 Protocol Independent Multicast (PIM): uses the IPv4 PIM protocol
to generate multicast routing entries and forwards multicast data based on multicast
routing entries. On an IPv4 multicast network, all Layer 3 devices must run IPv4 PIM;
otherwise, multicast forwarding paths cannot be established.

l Device running the Multicast Source Discovery Protocol (MSDP): forwards multicast
data from one PIM network to another. MSDP is mainly used on large-scale networks. If
multicast data needs to be transmitted between two autonomous systems (ASs), the
devices at the border of the two ASs must run the MSDP protocol.
l IGMP querier: exchanges IGMP messages with receiver hosts to create and maintain
group memberships. On a multicast network, Layer 3 devices connected to network
segments of receivers must run the IGMP protocol or be configured with static IGMP
groups. Otherwise, upstream PIM devices cannot know which multicast groups users
want to join, and therefore cannot establish multicast forwarding paths.
l Device running IGMP snooping: listens to IGMP messages exchanged between
upstream Layer 3 multicast devices and receiver hosts to create and maintain Layer 2
multicast forwarding entries, which are used for accurate multicast data forwarding on a
Layer 2 network. To prevent broadcasting of multicast packets on a Layer 2 network and
conserve network bandwidth, configure IGMP snooping on Layer 2 devices.
l Receiver: receives multicast data. A receiver can be a PC, a set top box, or any device
with a multicast client installed.
Licensing Requirements
IGMP is a basic software function of the switch. The license for basic software functions has
been loaded and activated before delivery. You do not need to manually activate it.
Version Requirements
Table 2-8 Products and minimum versions supporting this feature
Product Minimum Version

Required
CE5810EI V100R002C00
CE5850EI V100R001C00
CE5850HI V100R003C00
CE5855EI V100R006C00
CE5880EI V200R005C10
CE6810EI V100R003C00
CE6850EI V100R001C00
CE6850-48S6Q-HI V100R005C00
CE6850-48T6Q-HI/CE6850U-HI/CE6851HI V100R005C10
CE6855HI V200R001C00
CE6856HI V200R002C50
CE6857EI V200R005C10
CE6860EI V200R002C50


Required
CE6865EI V200R005C00
CE6870-24S6CQ-EI/CE6870-48S6CQ-EI V200R001C00
CE6870-48T6CQ-EI V200R002C50
CE6875EI V200R003C00
CE6880EI V200R002C50
CE6881/CE6820/CE6863 V200R005C20
CE7850EI V100R003C00
CE7855EI V200R001C00
CE8850-32CQ-EI V200R002C50
CE8850-64CQ-EI V200R005C00
CE8860EI V100R006C00
CE8861EI/CE8868EI V200R005C10
Feature Limitations
l To enable an interface to forward multicast data packets, you must enable PIM and
IGMP on the interface.
l In IGMPv3, CE series switches only process IGMPv3 INCLUDE mode Membership
Report messages in which the multicast group address is in the range of SSM group
addresses.
l When configuring IGMP SSM mapping on a switch, you are advised to enable IGMPv3
on interfaces of the switch to ensure that hosts running any IGMP version on the shared
network segment can obtain SSM services.
l IGMP cannot be used with VLAN mapping.
l The VLANIF interface of a super-VLAN can only function as a downstream interface in
a multicast routing entry.
l In the scenario when both Layer 2 and Layer 3 multicast are enabled, that is, when Layer
2 multicast is configured in a VLAN and Layer 3 multicast is configured on the
corresponding VLANIF interface, the following functions must be configured
simultaneously to ensure normal on-demand forwarding of multicast traffic:
– IGMP snooping must be enabled in a VLAN.
– PIM (PIM-SM or Bidir-PIM) and IGMP must be enabled on the corresponding
VLANIF interface.
l The CE6880EI, CE6881, CE6820, CE6863 and CE5880EI do not support IPv4 Layer 3
multicast, including IGMP and PIM, on its Layer 3 sub-interfaces.
l The IP address of a multicast source must be located on a different network segment
from the secondary IP address of the interface that connects to the multicast source.
Otherwise, multicast traffic may fail to be forwarded.

l When configuring multicast functions, you may need to adjust the (S, G) or (*, G) entry
timeout period based on the number of multicast entries used on your network. To set the
(S, G) or (*, G) entry timeout period, run the source-lifetime interval command in the
PIM view of the public network instance or a VPN instance. The following table lists the
recommended timeout period values in different conditions.
Number of Entries Recommended Timeout Period
Within 1000 Default value
1000 to 2000 1000 seconds
2000 to 8000 2000 seconds
More than 8000 4000 seconds
l When you configure IPv4 multicast together with other services, pay attention to the
following points:
Table 2-9 Precautions to be observed when you configure IPv4 multicast together with
other services
Item Precautions
IPv4 Layer 3 In versions earlier than V100R006C00, M-LAG does not support
multicast is IPv4 Layer 3 multicast.
deployed with
M-LAG

Item Precautions
In V100R006C00 and later versions, an M-LAG set up with

standalone switches, SVF systems, or stack systems supports IPv4
Layer 3 multicast. Pay attention to the following points:
l The M-LAG master and backup devices must have the same
multicast configuration.
l On the M-LAG master and backup devices, PIM-SM and IGMP
must be enabled on all the VLANIF interfaces that need to run
Layer 3 multicast services, and IGMP snooping must be enabled
in the corresponding VLANs.
l The PIM silent function must be configured on the user-side
interfaces of the M-LAG master and backup devices.
l In addition to the peer-link, there must be a direct Layer 3 link
between the M-LAG master and backup devices, and PIM must
be enabled on the interfaces at both ends of the Layer 3 link.
l If the Layer 3 link is established between VLANIF interfaces of
the M-LAG master and backup devices, STP must be disabled on
the VLANIF interfaces, and the corresponding VLAN of the
VLANIF interfaces cannot be allowed on the peer-link.
l If the peer-link is selected as the optimal link to the RP or
multicast source by the unicast routing protocol, multicast traffic
with the peer-link interface as the outbound interface may fail to
be forwarded. To prevent this problem, ensure that the Layer 3
link between the M-LAG master and backup devices has a route
cost smaller than or equal to the route cost of the peer-link, so
that the Layer 3 link is selected as the optimal route by the
unicast routing protocol.
On the network when the Receiver is dual-homed to an M-LAG:

l In versions earlier than V200R003C00, only the M-LAG master
member interface forwards multicast traffic to the Receiver.
l In V200R003C00 and later versions, both the M-LAG master
and backup member interfaces forward multicast traffic to the
Receiver, implementing load sharing. The M-LAG master and
backup devices share load according to the following rule: If the
last decimal number of the multicast group address is an odd
number, such as the address 225.1.1.1, the M-LAG master
member interface forwards the multicast traffic. If the last
decimal number of the multicast group address is an even
number, such as the address 225.1.1.2, the M-LAG backup
member interface forwards the multicast traffic.
l If the M-LAG master and backup devices run different versions,
the multicast traffic forwarding rule is subject to the device
running the earlier version.

2.6 Default Settings for IGMP

Table 2-10 lists the default settings for IGMP.
Table 2-10 Default settings for IGMP

Parameter Default Setting
IP multicast routing Disabled
IGMP Disabled
IGMP version IGMPv2
IGMP SSM mapping Disabled
IGMP general query interval 60s
Context
Hosts can connect to multicast networks and receive multicast packets after basic IGMP
configuration is complete on interfaces connected to user networks.
Pre-configuration Tasks
Before configuring IGMP basic functions, configure a unicast routing protocol to ensure that
multicast devices have reachable unicast routes to each other.
Configuration Procedure
2.7.1 Enabling IGMP and 2.7.2 Configuring the IGMP Version are mandatory. The other
configuration tasks are optional.
2.7.1 Enabling IGMP
Context
IP multicast routing is the prerequisite for all the multicast functions. Enable IP multicast
routing before configuring any multicast protocol.
To configure IGMP functions on the switch, first enable IGMP on interfaces connected to
group members.
Procedure
l Enabling IGMP in the public network instance

a. Run system-view
The system view is displayed.

b. Run multicast routing-enable
IP multicast routing is enabled.
By default, the IP multicast routing function is disabled.

c. Run interface interface-type interface-number
The interface view is displayed.

d. On an Ethernet interface, run undo portswitch
The interface is switched to Layer 3 mode.
By default, an Ethernet interface works in Layer 2 mode.
The mode switching function takes effect when the interface only has attribute
configurations (for example, shutdown and description configurations).
Alternatively, if configuration information supported by both Layer 2 and Layer 3
interfaces exists (for example, mode lacp and lacp system-id configurations), no
configuration that is not supported after the working mode of the interface is
switched can exist. If unsupported configurations exist on the interface, delete the
configurations first and then run the undo portswitch command.
If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch
batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in
the system view to switch these interfaces to Layer 3 mode in batches.
e. For a Layer 3 sub-interface, run the following commands to configure termination
of single-tagged packets on it.
i. Run quit
Return to the system view.
ii. Run interface interface-type interface-number.subinterface-number
The Layer 3 sub-interface view is displayed.
The subinterface-number parameter must specify a Layer 3 sub-interface
number on an Ethernet interface that has been switched to the Layer 3 mode.
iii. Run dot1q termination vid vid
Termination of Dot1q packets is configured on the Layer 3 sub-interface.
By default, the termination of Dot1q packets is not configured on a Layer 3
sub-interface.
f. Run pim sm
Protocol Independent Multicast Sparse Mode (PIM-SM) is enabled.

g. Run igmp enable
IGMP is enabled on the interface.
By default, IGMP is disabled on an interface.

When configuring IGMP on interfaces of CloudEngine 6800 series switches, you must also
enable PIM-SM on these interfaces so that they can forward multicast data packets.
h. Run commit
The configuration is committed.

l Enabling IGMP in a virtual private network (VPN) instance
A VPN instance must exist before you enable IGMP in the VPN instance.
a. Run system-view

b. Run ip vpn-instance vpn-instance-name
The VPN instance view is displayed.

c. Run ipv4-family
The IPv4 address family is enabled for the VPN instance, and the VPN instance
IPv4 address family view is displayed.
d. Run route-distinguisher route-distinguisher
An RD is configured for the VPN instance IPv4 address family.
A VPN instance IPv4 address family takes effect only after being configured with
an RD. The RDs of different VPN instances on a PE must be different.
e. Run multicast routing-enable
By default, the IP multicast routing function is disabled.

f. Run quit
Return to the VPN instance view.

g. Run quit

h. Run interface interface-type interface-number

i. On an Ethernet interface, run undo portswitch

j. For a Layer 3 sub-interface, run the following commands to configure termination
i. Run quit
sub-interface.
k. Run ip binding vpn-instance vpn-instance-name
The interface is bound to a specified VPN instance.
By default, an interface is a public network interface that is not associated with any
VPN instance.
l. Run pim sm
PIM-SM is enabled.
m. Run igmp enable
IGMP is enabled on the interface.
By default, IGMP is disabled on an interface.

n. Run commit
----End
2.7.2 Configuring the IGMP Version
Context
A multicast switch can identify IGMP messages of a version earlier than its own IGMP
version but cannot identify IGMP messages of a later version. To ensure normal IGMP
operation, ensure that the switch runs an IGMP version same as or later than the IGMP
version of member hosts.
If there are multiple multicast switches on a shared network segment of hosts, all host-side
interfaces of these switches must run the same IGMP version. If they are running different
IGMP versions, IGMP cannot function normally on the network.

Procedure
Step 1 Run system-view
Step 2 Run interface interface-type interface-number
Step 3 On an Ethernet interface, run undo portswitch
The mode switching function takes effect when the interface only has attribute configurations
(for example, shutdown and description configurations). Alternatively, if configuration
information supported by both Layer 2 and Layer 3 interfaces exists (for example, mode lacp
and lacp system-id configurations), no configuration that is not supported after the working
mode of the interface is switched can exist. If unsupported configurations exist on the
interface, delete the configurations first and then run the undo portswitch command.
If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch
interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to
switch these interfaces to Layer 3 mode in batches.
Step 4 For a Layer 3 sub-interface, run the following commands to configure termination of single-
tagged packets on it.
1. Run quit

2. Run interface interface-type interface-number.subinterface-number
The subinterface-number parameter must specify a Layer 3 sub-interface number on an

Ethernet interface that has been switched to the Layer 3 mode.
3. Run dot1q termination vid vid
By default, the termination of Dot1q packets is not configured on a Layer 3 sub-

interface.
Step 5 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 6 Run commit
----End

2.7.3 (Optional) Configuring a Static IGMP Multicast Group on

an Interface
Context
This configuration applies to some special scenarios, for example:
l There are long-term group members on a network segment.

l Hosts on a network segment cannot send Report messages, but multicast data needs to be
forwarded to the network segment.
In these scenarios, you can configure a static multicast group on the switch interface
connected to the network segment. Multicast data can then be quickly forwarded to the
network segment or be directed to the interface. 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 and always forwards multicast data of the group to the interface.
Procedure
1. Run quit



interface.
Step 5 Run the following commands to configure a static multicast group or source-group mapping
on the interface.
l For a Layer 3 sub-interface, run:
l For another type of interface, run:
By default, no static multicast group or source-group is configured on an interface.
If a static multicast group or source-group is configured on a loopback interface, the multicast switch
forwards multicast data to its downstream device only when users request the data. If a static multicast
group or source-group is configured on a non-loopback interface, the multicast switch forwards
multicast data to its downstream device immediately after receiving the data. You can configure static
multicast groups on a loopback interface if users have not requested data of these groups but may do so
later. If some multicast groups have stable receivers on a network segment, you can configure the static
multicast groups on the interface connected to this network segment.
Step 6 Run commit

----End
2.7.4 (Optional) Configuring the Range of IPv4 Multicast Groups

That an Interface Can Join
Context
To control the range of IPv4 multicast groups that hosts on an interface's network segment can
join, use an access control list (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 Series Switches Configuration Guide - Security.
Procedure


1. Run quit
interface.
Step 5 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.
When configuring an ACL rule for an interface, use the permit parameter in the rule command to allow
hosts connected to the interface to join groups within the specified range. If no rule is configured in the
ACL, hosts connected to the interface cannot join any groups.
Step 6 Run commit

----End
2.7.5 Verifying the Basic IGMP Function 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 [ vpn-instance vpn-instance-name | all-instance ] interface
[ interface-type interface-number | up | down ] [ verbose ] command to check the IGMP
configuration and running information on an interface.
l Run the display igmp [ vpn-instance vpn-instance-name | all-instance ] group [ group-
address | interface interface-type interface-number ]* [ verbose ] command to check
information about the members that have dynamically joined a multicast group.
address | interface interface-type interface-number ]* static [ verbose ] command to
check information about members of a static multicast group.
----End
2.8 Optimizing IGMP Performance
Context
After you configure basic IGMP functions, the switch can function the default IGMP
configuration. You can optimize IGMP parameter settings to enhance network security and
performance.
The following tasks are optional and can be performed in any order.
2.8.1 Configuring the IPv4 Router-Alert Option
Context
Generally, a network device sends a message to the corresponding protocol stack for
processing only when the destination address of the message is the address of a local
interface. IGMP messages therefore cannot be sent to the IGMP stack 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 message contains the Router-Alert option in the IP header, devices
that receive the message send the message to the corresponding protocol stack without
checking its destination IP address.
By default, the switch sends received IGMP messages to the IGMP stack for processing
regardless of whether the messages contain the Router-Alert option in their IP headers. This
ensures compatibility between the switch and other devices. Configuring the switch to discard
IGMP packets without the Router-Alert option can improve device performance, reduce
transmission cost, and enhance protocol security.
You can also configure the switch to send IGMP messages with or without the Router-Alert
option. By default, the switch sends IGMP messages with the Router-Alert option. If the

switch needs to communicate with a device that does not support the Router-Alert option,
configure the switch to send IGMP messages without the Router-Alert option.
The Router-Alert option can be configured in the IGMP view or interface view.
l Configuration in the IGMP view is valid globally, whereas configuration in the interface view is
valid only for the specific interface.
l If the Router-Alert option is configured in both the interface view and IGMP view, configuration in
the interface view takes precedence over 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
a. Run system-view
b. Run igmp [ vpn-instance vpn-instance-name ]
The IGMP view is displayed.
c. Run require-router-alert
The switch is configured to check the Router-Alert option in received IGMP
messages and drop IGMP messages without the Router-Alert option.
By default, the switch does not check whether the received IGMP messages contain
the Router-Alert option, and accepts all the received IGMP messages.
d. Run undo send-router-alert disable
The switch is configured to send IGMP messages with the Router-Alert option.
By default, IGMP messages sent by the switch contain the Router-Alert option.
e. Run commit
l Configuring the Router-Alert option on an interface
a. Run system-view
b. Run interface interface-type interface-number
c. On an Ethernet interface, run undo portswitch

d. For a Layer 3 sub-interface, run the following commands to configure termination
i. Run quit
sub-interface.
e. Run igmp require-router-alert
The interface is configured to check the Router-Alert option in received IGMP

messages and drop the IGMP messages without the Router-Alert option.
By default, the device does not check for the Router-Alert option in IGMP
messages and processes all the IGMP messages received on an interface.
f. Run undo igmp send-router-alert disable
The interface is configured to send IGMP messages with the Router-Alert option.
By default, IGMP messages sent by an interface contain the Router-Alert option.

g. Run commit
----End
2.8.2 Configuring IGMP Querier Parameters
Context
IGMP maintains group memberships using Query and Report messages. When multiple
multicast switches exist on a network segment, an IGMP querier is elected among them to
send IGMP Query messages. The IGMP querier can work normally using default settings of
querier parameters. You can modify the querier parameters to enable the querier to update
group membership in a timely manner and avoid network congestion.
Table 2-11 lists description and default setting of IGMP querier parameters.

Table 2-11 Description and Default setting of IGMP querier parameters

Parameter Description Default Setting
General query This parameter specifies the 60s

interval interval for sending IGMP General
Query messages. The querier sends
IGMP General Query messages at
specified intervals to maintain
group memberships of interfaces.
Robustness This parameter specifies the 2

variable of the retransmission count of IGMP
IGMP querier packets to minimize the impact of
packet loss on the network.
The robustness variable defines the
following values:
l Number of times the querier
sends General Query messages
after startup.
l Number of times the querier
sends Multicast Address
Specific Query messages or
Multicast Address and Source
Specific Query messages after
receiving a Done message.
Maximum After a multicast member receives 10s

response time an IGMP General Query message,
for IGMP it must send a Report message to
General Query the IGMP querier within the
messages maximum response time.
Other querier If non-querier routers do not 125s if the robustness variable,

present receive any Query message within interval for sending IGMP General
interval this interval, they consider the Query messages, and maximum
querier invalid and trigger election response time are all default values
of a new querier.
Group-specific This parameter specifies the 1s

or group-and- interval for sending Group-Specific
source- or Group-and-Source-Specific
specific query query messages. When the querier
interval receives a Leave message for a
group, it sends Group-Specific or
Group-and-Source-Specific query
messages at specified intervals to
check for other members in the
group.

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
a. Run system-view
b. Run igmp [ vpn-instance vpn-instance-name ]
c. Run timer query interval
The general query interval is configured.
The default general query interval is 60 seconds, which is different than the default
value 125 seconds defined by RFC documents. A Huawei querier and a non-
Huawei querier must send IGMP general query messages at the same interval.
d. Run robust-count robust-value
The robustness variable of the IGMP querier is configured.
e. Run max-response-time interval
The maximum response time for IGMP General Query messages is configured.
f. Run timer other-querier-present interval
The other querier present interval is configured.
g. Run lastmember-queryinterval interval
The group-specific or group-and-source-specific query interval is configured.
h. Run commit
Ensure that the general query interval is larger than the maximum response time for IGMP Query
messages and is smaller than the other querier present interval; otherwise IGMP Report messages
may not be sent in response to IGMP Query messages in a timely manner, causing the switch to
delete multicast entries.
l Configuring IGMP querier parameters on an interface
a. Run system-view


i. Run quit
sub-interface.
e. Run igmp timer query interval
The general query interval is configured.
The default general query interval is 60 seconds, which is different than the default
value 125 seconds defined by RFC documents. A Huawei querier and a non-
Huawei querier must send IGMP general query messages at the same interval.
f. Run igmp robust-count robust-value
The robustness variable of the IGMP querier is configured.
g. Run igmp max-response-time interval
The maximum response time for IGMP General Query messages is configured.
h. Run igmp timer other-querier-present interval
The other querier present interval is configured.
i. Run igmp lastmember-queryinterval interval
The group-specific or group-and-source-specific query interval is configured.

j. Run commit
Ensure that the general query interval is larger than the maximum response time for IGMP Query
messages and is smaller than the other querier present interval; otherwise IGMP Report messages
may not be sent in response to IGMP Query messages in a timely manner, causing the switch to
delete multicast entries.
----End
2.8.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

1. Run quit



interface.
Step 5 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 6 Run commit
----End
2.8.4 Configuring IGMP On-Demand
Context
In a standard IGMP working process, the querier periodically sends Query messages and
collects group membership information based on Report and Leave messages sent from hosts.
If group members on a network seldom change, you can configure IGMP on-demand on the
querier. IGMP on-demand enables the querier to maintain group memberships based on hosts'
requirements, without sending Query messages. This function reduces the number of IGMP
messages exchanged between the querier and hosts, conserving bandwidth on the network.
After you configure IGMP on-demand on an interface of the switch:
l The interface no longer sends IGMP Query messages.

l The switch creates IGMP group entries after receiving IGMP Report messages. The
entries will never age out.
l The switch deletes a group entry immediately after receiving an IGMP Leave message
for the group.
IGMP on-demand applies only to IGMPv2 and IGMPv3.
Procedure

Step 4 Run igmp on-demand
IGMP on-demand is enabled on the interface. The interface no longer sends IGMP Query
messages, and IGMP group entries on the interface will never age out.
By default, an interface periodically sends Query messages and participates in querier

election.
The querier does not process dynamic IGMP entries that have been generated before IGMP on-demand
is enabled on it.
Step 5 Run commit
----End
2.8.5 Configuring IGMP Host Tracking
Context
When an IGMPv3 host leaves a multicast group on a network running IGMPv3, an IGMP
querier sends a Group-Specific Query message to the multicast group address. If the querier
does not receive any response from the host within the specified time, it considers that the
host has left the multicast group. While the IGMP querier waits for a response from the host,
the multicast device continues to forward multicast traffic to the host. This delays the
switching of multicast programs and wastes bandwidth.
You can configure the host tracking function to address this problem. After this function is
enabled, the IGMP querier will create an entry when a host joins a group. Upon receipt of a
Leave message sent by a host, the IGMP querier considers that the host has left the multicast
group and stops sending Group-Specific Query messages.

Host tracking supports only IGMPv3, and can be configured only on interfaces connected to
only IGMPv3 capable hosts.
Procedure
Step 4 Run igmp explicit-tracking

The host tracking function is enabled on the interface.
By default, host tracking is disabled on an interface.
Step 5 Run commit
----End
2.8.6 Filtering IGMP Messages Based on Source IPv4 Addresses
Context
A Layer 3 multicast switch directly connected to a user network segment processes all the
IGMP messages received. To improve security and prevent multicast services from being
affected by IGMP messages maliciously forged by other devices, you can configure IGMP
message filtering on switch interfaces connected to hosts. The switch supports filtering of
IGMP Query, Report and Leave messages.
Procedure

1. Run quit



interface.
Step 5 Run igmp query ip-source-policy { basic-acl-number | acl-name acl-name }
A policy is configured on the interface to filter Query messages based on source IP addresses.
By default, the switch does not filter Query messages and processes all the received Query
messages.
When configuring an ACL rule for the interface, use the permit parameter to configure the interface to
accept only Query messages with source addresses in a specified range. If no rule is configured in the
ACL, the interface denies all IGMP Query messages.
Step 6 Run igmp ip-source-policy [ basic-acl-number | acl-name acl-name ]

A policy is configured on the interface to filter 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 without specifying an ACL, 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.
When configuring an ACL rule for the interface, use the permit parameter to configure the interface to
accept only Report/Leave messages with source addresses in a specified range. If no rule is configured
in the ACL, the interface denies all IGMP Report/Leave messages.
Step 7 Run commit
----End
2.8.7 Verifying the Configuration of IGMP Performance

Parameters
Context
You can run the following commands in any view to check the adjusted membership
information, IGMP configuration, and IGMP running information.
Procedure
address | interface interface-type interface-number ]* [ verbose ] command to check
information about IGMP groups that hosts have dynamically joined by sending IGMP
Report messages.
[ interface-type interface-number | up | down ] [ verbose ] command to check the IGMP
configuration and running information on an interface.
----End
2.9 Configuring IGMP SSM Mapping
2.7.1 Enabling IGMP

Context
The source-specific multicast (SSM) model allows IGMPv3 hosts to specify the multicast
sources from which they want to receive data. However, some hosts can only run IGMPv1 or
IGMPv2. To enable these hosts to use the SSM service, configure IGMP SSM mapping on the
switch. IGMP SSM mapping is implemented based on static SSM mapping entries on the
switch. The switch converts (*, G) information in IGMPv1 and IGMPv2 Report messages to
(S, G) information according to static SSM mapping entries to provide the SSM service for
IGMPv1 and IGMPv2 hosts. By default, SSM group addresses range from 232.0.0.0 to
232.255.255.255. You can expand this range if required. For details, see 3.8.2.2 (Optional)
Configuring an SSM Group Policy.
Procedure
1. Run quit
interface.

Step 5 Run igmp ssm-mapping enable

IGMP SSM mapping is enabled on the interface.
By default, IGMP SSM mapping is disabled on an interface.
Enable IGMPv3 on switch interfaces to ensure that hosts running any IGMP version on a
network segment can obtain the SSM service.
Step 6 Run quit
Step 7 Run igmp [ vpn-instance vpn-instance-name ]
Step 8 Run ssm-mapping group-address { group-mask | group-mask-length } source-address
An SSM mapping rule is configured to map a group address to a multicast source.
By default, no SSM mapping rule is configured.
Step 9 Run commit
----End
Verifying the Configuration

Run the following commands in any view to check the configured mapping entries and
whether IGMP SSM mapping is enabled on the interface.
address | interface interface-type interface-number ]* ssm-mapping [ verbose ]
command to check information about group memberships established with IGMP SSM
mapping.
l Run the display igmp [ vpn-instance vpn-instance-name | all-instance ] ssm-mapping
{ group [ group-address ] | interface [ interface-type interface-number ] } command to
check SSM mapping entries configured and whether IGMP SSM mapping is enabled on
an interface.
2.10 Maintaining IGMP
2.10.1 Resetting IGMP Group Memberships
Context
NOTICE
After IGMP group memberships are reset, group members may fail to receive multicast data.
Confirm your operation before clearing IGMP group information.

Procedure
l Run the reset igmp [ vpn-instance vpn-instance-name | all-instance ] 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 reset dynamic IGMP entries on interfaces.
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 reset static group memberships.
l Run the reset igmp [ vpn-instance vpn-instance-name | all-instance ] group ssm-
mapping { all | interface interface-type interface-number { all | group-address [ mask
{ group-mask | group-mask-length } ] } } command in the user view to reset group
memberships established with IGMP SSM mapping.
----End
2.10.2 Resetting IGMP Packet Statistics
Context
To view accurate statistics about IGMP control packets within a given period, reset existing
statistics first.
NOTICE
Statistics about IGMP control packets cannot be restored after you reset them. Exercise
caution before resetting statistics.
Procedure
l Run the reset igmp [ vpn-instance vpn-instance-name | all-instance ] control-message
counters [ interface interface-type interface-number ] [ message-type { query |
report } ] command in the user view to clear IGMP control packet statistics.
----End
2.10.3 Monitoring the IGMP Running Status
Context
Run the following display commands in any view to check the IGMP running status during
routine maintenance.
Procedure
address | interface interface-type interface-number ]* [ verbose ] command to display
information about the members that have dynamically joined a multicast group.


address | interface interface-type interface-number ]* static [ verbose ] command to
display information about members of a static multicast group.
[ interface-type interface-number | up | down ] [ verbose ] command to display the
IGMP configuration and running information on an interface.
address | interface interface-type interface-number ]* ssm-mapping [ verbose ]
command to display information about group memberships established with SSM
mapping.
l Run the display igmp [ vpn-instance vpn-instance-name | all-instance ] ssm-mapping
{ group [ group-address ] | interface [ interface-type interface-number ] } command to
display SSM mapping entries configured and whether SSM mapping is enabled on an
interface.
l Run the display igmp [ vpn-instance vpn-instance-name | all-instance ] control-
message counters [ interface interface-type interface-number ] [ message-type { query
| report } ] command check statistics about IGMP messages.
l Run the following commands to check statistics about invalid IGMP messages and
detailed information about these messages.
– Run the display igmp [ vpn-instance vpn-instance-name | all-instance ] invalid-
packet [ interface interface-type interface-number | message-type { leave | query |
report } ]* command to display statistics about invalid IGMP messages.
– Run the display igmp invalid-packet [ packet-number ] verbose command to
display detailed information about the latest invalid IGMP messages received on the
device.
----End
2.11 Configuration Examples for IGMP

This section only provides configuration examples for individual features. For details about
multi-feature configuration examples, feature-specific configuration examples, interoperation
examples, protocol or hardware replacement examples, and industry application examples, see
the Typical Configuration Examples.
2.11.1 Example for Configuring Basic IGMP Functions
Networking Requirements
In Figure 2-16, users are located on network segments N1 and N2. On the Protocol
Independent Multicast (PIM) network, SwitchA connects to network segment N1, whereas
SwitchB and SwitchC connect to network segment N2. The PIM network uses multicast
addresses 225.1.1.1 through 225.1.1.5 to transmit video streams.
HostA on N1 and HostC on N2 want to receive video streams in multicast mode. HostA only
subscribes to videos of group 225.1.1.1, and HostC subscribes to videos of all groups. You
need to configure the switches to allow HostA to receive only video streams of group
225.1.1.1 while allowing HostC to receive video streams of all groups.

Figure 2-16 Network diagram for basic IGMP configuration
PIM network N1 Receiver
10GE1/0/1
/ 0 /2 VLANIF10
G E1 IF11 10.110.1.1/24 HostA
10 LAN .1/24
V 8.1
.16
192
.1 /0/1 192 SwitchA
VLA 68.4.2 G E1 F11 /24
10G NIF4 /24 10 LANI 8.1.2 HostB
E1/ 0
0/4 V .16 10GE1
192 /0/2 10GE1/0/1
V
10GE1/0/2192.1 LANIF21 VLANIF20
68.2.1/2
VLANIF21 4 10.110.2.1/24 Receiver
SwitchD 10G 192.168.2.2/24
VL E1/
192 ANIF 0/3 SwitchB
.16 31 HostC
8.3 10GE1/0/1
.2/2 10G VLANIF20
4
192 VLA E1/0/2 10.110.2.2/24
.16 NIF
8.3 31
.1/2
4 SwitchC HostD
N2
Configuration Roadmap
To meet the preceding requirements, configure basic IGMP functions on the switches, and
configure a group policy on SwitchA to limit the multicast group range on the interface
connected to network segment N1. The configuration roadmap is as follows:
1. To ensure normal operating of the multicast routing protocol, configure a unicast routing
protocol on the network to implement IP interworking. Multicast routing protocols are
dependent on unicast routing protocols.
2. To enable the switches to forward video streams to the hosts in multicast mode,
configure basic multicast functions on the switches.
3. To allow HostA to receive only multicast data sent to multicast group 225.1.1.1,
configure a group policy on SwitchA's interface connected to N1 to filter multicast data
sent to this network segment.
Procedure
Step 1 Configure IP addresses for interfaces and configure a unicast routing protocol on each switch.
# Configure IP addresses and masks for switch interfaces according to Figure 2-16.
Configure Open Shortest Path First (OSPF) on the switches to implement IP interworking and
dynamic route update. The configurations of SwitchB, SwitchC, and SwitchD are similar to
the configuration of SwitchA, and are not mentioned here. See Configuration Files.
<HUAWEI> system-view
[~HUAWEI] sysname SwitchA
[*HUAWEI] commit
[~SwitchA] vlan batch 10 11
[*SwitchA] interface 10ge 1/0/1
[*SwitchA-10GE1/0/1] port link-type access

[*SwitchA-10GE1/0/1] port default vlan 10

[*SwitchA-10GE1/0/1] quit
[*SwitchA-10GE1/0/2] port link-type trunk
[*SwitchA-10GE1/0/2] port trunk allow-pass vlan 11
[*SwitchA] interface vlanif 10
[*SwitchA-Vlanif10] ip address 10.110.1.1 24
[*SwitchA-Vlanif10] quit
[*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 IP multicast routing on all the switches and enable Protocol Independent Multicast
Sparse Mode (PIM-SM) on all interfaces.
# Enable IP multicast routing on SwitchA and enable PIM-SM on all its interfaces. The
configurations of SwitchB, SwitchC, and SwitchD are similar to the configuration of
SwitchA, and are not mentioned here. See Configuration Files.
[~SwitchA] multicast routing-enable
[*SwitchA-Vlanif10] pim sm
[*SwitchA-Vlanif10] commit
[~SwitchA-Vlanif10] quit
[~SwitchA] interface vlanif 11
[~SwitchA-Vlanif11] pim sm
Step 3 Configure a static rendezvous point (RP).

# Configure a static RP on SwitchA. Specify VLANIF40 of SwitchD as the static RP. The
[~SwitchA] pim
[*SwitchA-pim] static-rp 192.168.4.2
[*SwitchA-pim] commit
[~SwitchA-pim] quit
Step 4 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. See Configuration Files.
[~SwitchA-Vlanif10] igmp enable
Step 5 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 6 Verify the configuration.

# Run the display igmp interface command on each switch to check the IGMP configuration
and running status on each interface.
The IGMP command output on VLANIF10 of SwitchA is as follows:
[~SwitchA] display igmp interface vlanif 10
Interface information of VPN instance: public net
Vlanif10(10.110.1.1):
IGMP is enabled
Current IGMP version is 2
IGMP state: up
IGMP group policy: 2001
IGMP limit: -
Query interval for IGMP (negotiated): -
Query interval for IGMP (configured): 60 s
Other querier timeout for IGMP: 0 s
Maximum query response time for IGMP: 10 s
Querier for IGMP: 10.110.1.1 (this router)
Total 1 IGMP Group reported
The command output shows that IGMP is enabled on VLANIF10 of SwitchA, and a group
policy referencing ACL 2001 has been applied to this interface. In addition, VLANIF10 has
received a Report message of a multicast group.
The IGMP command output on VLANIF20 of SwitchB is as follows:
[~SwitchB] display igmp interface vlanif 20
Vlanif20(10.110.2.1):
IGMP is enabled
IGMP state: up
IGMP group policy: none
IGMP limit: -
Total 2 IGMP Groups reported
The command output shows that SwitchB is a querier. This is because the IP address of
VLANIF20 on SwitchB is the smallest on the network segment. In addition, VLANIF20 has
received Report messages of two multicast groups.
# Run the display pim routing-table command to check the PIM-SM routing table on each
switch.
On the shared network segment where SwitchB and SwitchC are located, SwitchB is elected
as the multicast data forwarder. The PIM-SM routing table on SwitchB is as follows:
[~SwitchB] display pim routing-table
VPN-Instance: public net
Total 2 (*, G) entries; 2 (S, G) entries
(*, 225.1.1.1)
RP: 192.168.4.2
Protocol: pim-sm, Flag: WC
UpTime: 00:21:35

Upstream interface: Vlanif21

Upstream neighbor: 192.168.2.2
RPF prime neighbor: 192.168.2.2
Downstream interface(s) information:
Total number of downstreams: 1
1: Vlanif20
Protocol: igmp, UpTime: 00:21:35, Expires: -
(193.3.5.2, 225.1.1.1)
RP: 192.168.4.2
Protocol: pim-sm, Flag: SPT ACT
UpTime: 00:42:46
1: Vlanif20
Protocol: pim-sm, UpTime: 00:21:35, Expires: -
(*, 225.1.1.2)
RP: 192.168.4.2
UpTime: 00:06:02
1: Vlanif20
(193.3.5.2, 225.1.1.2)
RP: 192.168.4.2
UpTime: 00:15:12
1: Vlanif20
The command output shows that (*, 225.1.1.1), (193.3.5.2, 225.1.1.1), (*, 225.1.1.2), and
(193.3.5.2, 225.1.1.2) entries exist on SwitchB. This indicates that VLANIF20 has joined
multicast groups 225.1.1.1 and 225.1.1.2 and can receive multicast data from multicast source
193.3.5.2.
The PIM-SM routing table on SwitchA is as follows:
[~SwitchA] display pim routing-table
Total 1 (*, G) entry; 1 (S, G) entry
(*, 225.1.1.1)
RP: 192.168.4.2
UpTime: 00:21:35
1: Vlanif10
(193.3.5.2, 225.1.1.1)

RP: 192.168.4.2
UpTime: 00:42:46
1: Vlanif10
The command output shows that only (*, 225.1.1.1) and (193.3.5.2, 225.1.1.1) entries exist on
SwitchA. This is because a group policy is configured on VLANIF10 of SwitchA.
----End
Configuration Files
l SwitchA configuration file
#
sysname SwitchA
#
vlan batch 10 to 11
#
multicast routing-enable
#
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.2
#
return
l SwitchB configuration file

#
sysname SwitchB
#
vlan batch 20 to 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
#
pim
static-rp 192.168.4.2
#
return
l SwitchC configuration file
#
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.2
#
return
l SwitchD configuration file
#
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.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.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.2
#
return
2.11.2 Example for Configuring a Static IPv4 Multicast Group on

an Interface
In Figure 2-17, users are located on network segments N1 and N2. On the Protocol
Independent Multicast (PIM) network, SwitchA connects to network segment N1, whereas
SwitchB and SwitchC connect to network segment N2. The PIM network uses multicast
addresses 225.1.1.1 through 225.1.1.5 to transmit video streams.
HostA on N1 and HostC and HostD on N2 want to receive video streams in multicast mode.
HostA wants to receive data of group 225.1.1.1 for a long time, whereas HostC and HostD do
not have such requirements.

Figure 2-17 Network diagram for static multicast group configuration
PIM network N1 Receiver
10GE1/0/1
/0/2 VLANIF10
G E1 IF11 10.110.1.1/24 HostA
1 LAN .1/24
0
V 8.1
.16
192
. /0/1 192
VLA 168.4.1 G E1 F11 /24 SwitchA
10G NIF4 /24 10 LANI 8.1.2 HostB
E1/ 0
0/4 V .16 10GE1
192 /0/2 10GE1/0/1
V
10GE1/0/2192.1 LANIF21 VLANIF20
68.2.1/2
VLANIF21 4 10.110.2.1/24
SwitchD 10G 192.168.2
.2/24
VL E1/0
192 ANIF /3 SwitchB
.16 31 HostC
8.3 10GE1/0/1
.2/2 10G VLANIF20 Receiver
4
V
192 LA E 1 10.110.2.2/24
/0
.16 NIF /2
8.3 1 3
.1/2
4 SwitchC HostD
N2
Receiver
Based on the requirement of HostA, you need to configure static multicast group 225.1.1.1 on
SwitchA's interface connected to N1. The configuration roadmap is as follows:
2. To enable the switches to forward video streams to the hosts in multicast mode,
configure basic multicast functions on the switches.
3. To enable HostA to receive data of group 225.1.1.1 in a long time, statically bind
SwitchA's interface connected to N1 to this group.
Procedure
[*HUAWEI] commit


[*SwitchA] ospf
Step 2 Enable IP multicast routing on each switch and enable Protocol Independent Multicast Sparse
Mode (PIM-SM) on all interfaces.
configurations of SwitchB, SwitchC and SwitchD are similar to the configuration of SwitchA,
and are not mentioned here. See Configuration Files.
Step 3 Configure a static rendezvous point (RP).

# Configure a static RP on SwitchA. Specify VLANIF40 of SwitchD as the static RP. The
[~SwitchA] pim
[~SwitchA-pim] quit
Step 4 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. See Configuration Files.
Step 5 Statically bind VLANIF10 of SwitchA to group 225.1.1.1 so that hosts connected to
VLANIF10 can receive stable multicast data sent to this group.
[~SwitchA-Vlanif10] igmp static-group 225.1.1.1

# Run the display igmp interface command to check the IGMP configuration and running
status on each interface. The IGMP command output on VLANIF20 of SwitchB is as follows:

[~SwitchB] display igmp interface vlanif 20

Vlanif20(10.110.2.1):
IGMP is enabled
IGMP state: up
IGMP group policy: none
IGMP limit: -
Total 2 IGMP Groups reported
The command output shows that IGMP is enabled on VLANIF20 of SwitchB.

# Run the display pim routing-table command on SwitchA. You can see that VLANIF10 has
been statically bound to multicast group 225.1.1.1. The command output information is as
follows:
(*, 225.1.1.1)
RP: 192.168.4.1
UpTime: 00:12:17
1: Vlanif10
Protocol: static igmp, UpTime: 00:12:17, Expires: -
The command output shows that SwitchA has a (*, 225.1.1.1) entry, with the downstream
interface VLANIF10 and protocol type static igmp. This verifies that VLANIF10 has been
statically bound to multicast group 225.1.1.1. If IGMP is disabled on VLANIF10 of SwitchA,
the protocol type is static.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 to 11
#
#
interface Vlanif10
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp static-group 225.1.1.1
#
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 to 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
#
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
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.11.3 Example for Configuring IGMP SSM Mapping

In Figure 2-18, the network runs Protocol Independent Multicast Sparse Mode (PIM-SM) and
uses the source-specific multicast (SSM) model to provide multicast services to group
members. SwitchD's interface VLANIF13 connected to the network segment of Receiver runs
IGMPv3. Receiver runs IGMPv2 and does not support IGMPv3; therefore, Receiver cannot
specify desired multicast sources when it joins a group. The SSM group address range on the
network is 232.1.1.0/24. Source1, Source2, and Source3 all send multicast data to the
multicast groups in this range.
Receiver needs to obtain the SSM service and wants to receive only multicast data sent from
Source1 and Source3.
Figure 2-18 Network diagram for IGMP SSM mapping configuration
PIM-SM
Source2 Source3
SwitchB 192.168.2.1/24 192.168.2.2/24 SwitchC
VLANIF31 VLANIF31
10GE1/0/1 10GE1/0/3 10GE1/0/3 10GE1/0/1
VLANIF11 VLANIF12
10.10.2.2/24 10GE1/0/2 10GE1/0/2 10.10.3.2/24
10.10.2.1/24 VLANIF21 10.10.3.1/24
VLANIF20
192.168.1.2/24 192.168.3.1/24
192.168.1.1/24 192.168.3.2/24
Source1 10.10.1.2/24 VLANIF20 VLANIF21 10GE1/0/1
VLANIF13 Receiver
VLANIF10 10GE1/0/2 10GE1/0/2
10GE1/0/1 10.10.4.2/24
10GE1/0/3 10GE1/0/3
VLANIF30 VLANIF30
10.10.1.1/24 SwitchA 192.168.4.2/24 192.168.4.1/24 SwitchD
10.10.4.1/24
Based on the receiver's requirement, you need to configure IGMP SSM mapping on SwitchD.
The configuration roadmap is as follows:
2. To enable the switches to forward multicast data to Receiver, configure basic multicast
functions on switches.
3. To allow Receiver to receive data from specified multicast sources, enable IGMP SSM
mapping and configure mapping rules on SwitchD.
Procedure

[*HUAWEI] commit
[~SwitchA] vlan batch 10 20 30
[*SwitchA] ospf
Step 2 Enable IP multicast routing on all the switches and enable PIM-SM on all interfaces.
Step 3 Enable IGMP on the interface of SwitchD connected to Receiver and set the IGMP version to
IGMPv3.
# Enable IGMP on VLANIF13 of SwitchD and set the IGMP version to IGMPv3.
[~SwitchD] interface vlanif 13
[~SwitchD-Vlanif13] igmp enable
[*SwitchD-Vlanif13] igmp version 3

[*SwitchD-Vlanif13] commit
[~SwitchD-Vlanif13] quit
Step 4 Enable IGMP SSM mapping on the interface connected to the receiver network segment.
# Enable IGMP SSM mapping on VLANIF13 of SwitchD.
[~SwitchD-Vlanif13] igmp ssm-mapping enable
Step 5 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. See Configuration Files.
[*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
Step 6 Configure IGMP SSM mapping rules on SwitchD.

# On SwitchD, map the multicast groups in the range of 232.1.1.0/24 to Source1 and Source3.
[~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

# Run the display igmp ssm-mapping group command on SwitchD to view the mappings
between multicast sources and multicast groups.
[~SwitchD] display igmp ssm-mapping group
IGMP SSM-Mapping conversion table of VPN instance: public net
Total entries: 2 (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 preceding information shows that multicast groups in the range of 232.1.1.0/24 are
mapped to Source1 and Source3.
# Run the display igmp group ssm-mapping command on SwitchD to view information
about multicast 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
Limited entry of this VPN instance: -
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

The preceding information shows that Receiver has joined group 232.1.1.1.
# 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
Total 2 (S, G) entries
(10.10.1.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: -
(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: -
You can see that multicast sources 10.10.1.1 and 10.10.3.1 send data to group 232.1.1.1, and
SwitchD receives the multicast data from the two multicast sources through interfaces
VLANIF30 and VLANIF21 respectively.
----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
#
#
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
l SwitchC configuration file configuration file
#
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
#
ospf 1
area 0.0.0.0
network 10.10.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
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 Vlanif21
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.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
ssm-policy 2000
#
return
2.12 Troubleshooting IGMP
2.12.1 IGMP Entries Cannot Be Created
Fault Description
After IGMP configuration is complete, hosts request data of multicast group G. However, the
last-hop multicast device does not create any IGMP entries.
Procedure
Step 1 Check whether the requested 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 Up.
If the interface is Down, check whether the interface is correctly connected, whether it has
been shut down using the shutdown command, and whether it 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, run the igmp enable command in the
interface view to enable IGMP.
Step 5 Run the display igmp [ vpn-instance vpn-instance-name | all-instance ] interface interface-
type interface-number command to check whether the IGMP configuration on the interface is
correct.

l The IGMP version running on the interface (identified by Current IGMP version in the
command output) 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.12.2 (S, G) Entries Are Not Generated After IGMP SSM

Mapping Is Enabled
Fault Description
An interface is enabled with source-specific multicast (SSM) mapping and IGMP, and is
configured with a static SSM mapping policy. The interface has received IGMPv1 or IGMPv2
Report messages, but multicast forwarding information base (MFIB) table does not contain
the (S, G) entries matching the SSM mapping entries.
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 "ssm-policy", 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 to 232.255.255.255.
----End

Configuration Guide - IP Multicast 3 IPv4 PIM Configuration
3 IPv4 PIM Configuration
This chapter describes how to configure IPv4 PIM to enable multicast data routing and
forwarding on an IPv4 network.
"Router" mentioned in this chapter and the router icon used in figures refer to a conventional router or
Layer 3 switch.
3.1 Overview of PIM

3.2 Understanding PIM
3.3 Application Scenarios for PIM
3.4 Summary of IPv4 PIM Configuration Tasks
3.5 Licensing Requirements and Limitations for IPv4 PIM
3.6 Default Settings for IPv4 PIM
3.7 Configuring IPv4 PIM-DM
3.8 Configuring IPv4 PIM-SM
3.9 Configuring IPv4 Bidir-PIM
3.10 Maintaining IPv4 PIM-DM
3.11 Maintaining IPv4 PIM-SM
3.12 Maintaining IPv4 Bidir-PIM
3.13 Configuration Examples for IPv4 PIM
3.14 Troubleshooting IPv4 PIM
3.1 Overview of PIM
Definition
Protocol Independent Multicast (PIM) is a multicast routing solution that performs a reverse
path forwarding (RPF) check on multicast packets based on the unicast routing table, creates

multicast routing entries if multicast packets pass the RPF check, and forwards the multicast
packets using multicast routing entries. PIM is termed protocol-independent because it is not
dependent on any particular unicast routing protocol for topology discovery.
Currently, the device supportsPIM-DM, bidirectional PIM and PIM-SM.
Purpose
In 1992, the multicast backbone (Mbone) was established as a virtual backbone for IP
multicast traffic to support network video and audio conferencing. Mbone uses multicast open
shortest path first (MOSPF) and the Distance Vector Multicast Routing Protocol (DVMRP) as
multicast routing protocols.
Mbone promotes the use and development of multicast technologies and routing protocols.
However, new problems are created because various multicast routing protocols are widely
used. If multicast routes like unicast are dynamically generated using different routing
algorithms, complex operations such as route import are required. Network devices will then
need to maintain both unicast and multicast routing information.
PIM was developed to simplify operations and reduce network device load. This solution
maintains only the information about multicast group members and the multicast source
status. PIM reduces protocol implementation complexity because there is no need to maintain
a large amount of routing information. Instead, routing information is obtained from only the
unicast routing table. As a result, PIM became the most widely used intra-domain multicast
protocol.
A PIM network is comprised of multiple PIM routers. A large PIM network can be partitioned into
multiple PIM domains to manage and control multicast packet forwarding.
3.2 Understanding PIM
3.2.1 Concepts
This section describes PIM-related concepts based on the network shown in Figure 3-1.

Figure 3-1 PIM network
Source
RouterE
RouterD Int3
Int1
RouterA RouterC
Int2
RouterB
HostA HostC
Receiver HostB
Receiver
Multicast packets
Upstream interfaces
Downstream interfaces
Multicast Distribution Tree

On a PIM network, a point-to-multipoint (P2MP) multicast forwarding path is established for
each multicast group on separate routers. The multicast forwarding path looks like a tree, so it
is also called a multicast distribution tree (MDT).
Two types of MDTs are available:
l Shortest path tree (SPT): uses the multicast source as the root and multicast group
members as leaves. SPT applies to both PIM-DM and PIM-SM networks.
In Figure 3-1, the MDT, RouterE→RouterD→RouterA/RouterB, is an SPT, which uses
the source as the root and HostA and HostB as leaves.
l Rendezvous point tree (RPT): uses a rendezvous point (RP) as the root and multicast
group members as leaves. RPT applies to PIM-SM or Bidir-PIM networks.
For details about RP and RPT, see 3.2.3 PIM-SM (ASM Model).
Leaf hosts of an RPT on a Bidir-PIM network may not only receive multicast data as group
members, but also forward multicast data as multicast sources. That is, multicast data is forwarded
bidirectionally on the RPT, so the RPT on a Bidir-PIM network is also called a Bidir RPT. For
details about Bidir RPT, see 3.2.5 Bidir-PIM.
PIM Router
Routers with PIM enabled on interfaces are called PIM routers. During the establishment of
an MDT, PIM routers play the following roles:
l Leaf router: connects to user hosts, which may not be multicast group members. For
example, RouterA, RouterB, and RouterC in Figure 3-1 are leaf routers.

l First-hop router: directly connects to the multicast source on the multicast forwarding
path and is responsible for forwarding multicast data from the multicast source. For
example, RouterE in Figure 3-1 is the first-hop router.
l Last-hop router: directly connects to multicast group members (receivers) on the
multicast forwarding path and is responsible for forwarding multicast data to these
members. For example, RouterA and RouterB in Figure 3-1 are last-hop routers.
l Intermediate router: resides between the first-hop router and the last-hop router on the
multicast forwarding path. For example, RouterD in Figure 3-1 is an intermediate router.
PIM Routing Entry

Two types of PIM routing entries are generated using PIM: (S, G) and (*, G); S indicates a
specific multicast source, G indicates a specific multicast group, and * indicates any multicast
source.
l (S, G) entries are often used to establish an SPT on a PIM network. (S, G) entries apply
to PIM-DM and PIM-SM network.
l (*, G) entries are often used to establish an RPT on a PIM network. (*, G) entries apply
to PIM-SM and Bidir-PIM networks.
A PIM router may have both (S, G) and (*, G) entries. When a PIM router receives a
multicast packet with the source address S and the group address G and the packet passes the
RPF check, the router forwards the packet according to the following rules:
l If the (S, G) entry exists, the router forwards the packet according to the (S, G) entry.
l If the (S, G) entry does not exist but the (*, G) entry exists, the router creates an (S, G)
entry based on this (*, G) entry, and then forwards the packet according to the (S, G)
entry.
PIM routing entries contain the following information to guide multicast packet forwarding:
l Multicast source address
l Multicast group address
l Upstream interface, which receives multicast data on the local router, such as Int3 in
Figure 3-1
l Downstream interface, which forwards multicast data, such as Int1 and Int2 in Figure
3-1
3.2.2 PIM-DM
Implementation
PIM-DM forwards multicast packets in push mode and is for use on small-scale networks
with densely distributed multicast group members. PIM-DM assumes that each network
segment has multicast group members. When a multicast source sends multicast packets,
PIM-DM floods all PIM routers on the network with the multicast packets and prunes the
branches that do not have multicast group members. Through periodic flooding and pruning,
PIM-DM creates and maintains a unidirectional loop-free SPT that connects the multicast
source and group members. If a new member joins a multicast group on the network segment
connected to a leaf router in a pruned branch, the router can initiate the graft mechanism
before starting new flooding and prune. As a result, the pruned branch turns into a forwarding
branch.

PIM-DM uses the following mechanisms: neighbor discovery, flooding, prune, graft, assert,
and state refresh. The flooding, prune, and graft mechanisms are used to establish an SPT. For
details about all of these six mechanisms, see the sections below.
Neighbor Discovery
PIM routers send Hello messages through PIM-enabled interfaces. Iin a Hello message:
l The destination address is 224.0.0.13 and all PIM routers on the same network segment
will receive this Hello message.
l The source address is the IP address of the interface that sent the Hello message.
l The time to live (TTL) value is 1.
Hello messages are used to discover PIM neighbors, adjust various PIM protocol parameters,
and maintain neighbor relationships.
l Discovering PIM neighbors
PIM routers on the same network segment must receive multicast packets with the
destination address 224.0.0.13. By exchanging Hello messages, directly connected PIM
routers learn neighbor information and establish neighbor relationships.
A PIM router can receive other PIM messages to create multicast routing entries only
after it establishes neighbor relationships with other PIM routers.
l Adjusting PIM protocol parameters
A Hello message carries the following PIM protocol parameters for controlling PIM
protocol packet exchange between PIM neighbors:
– DR_Priority: indicates the priority used by router interfaces to elect the designated
router (DR). The interface with the highest priority becomes the DR.
– Holdtime: indicates the period during which a neighbor remains reachable. If a
router receives no Hello message from a neighbor within this period, the router
considers that the neighbor is unreachable.
– LAN_Delay: indicates the delay in transmitting Prune messages on a shared
network segment.
– Override-Interval: indicates the interval for overriding the prune mechanism.
The DR_Priority parameter is only used in DR election on PIM-SM networks. For details about
DR election, see "PIM-SM (ASM model) DR Election".
l Maintaining neighbor relationships
PIM routers periodically send Hello messages to each other. If a PIM router does not
receive a new Hello message from its PIM neighbor within the holdtime, the router
considers the neighbor unreachable and deletes the neighbor from the neighbor list.
Changes of PIM neighbors lead to multicast topology changes on the network. If an
upstream or downstream neighbor in the MDT is unreachable, multicast routes re-
converge and the MDT is re-established.
Flooding
On a PIM-DM network, multicast packets from a multicast source are flooded throughout the
entire network. When a PIM router receives a multicast packet, the router performs the RPF
check on the packet based on the unicast routing table. If the packet passes the RPF check, the

router creates an (S, G) entry, in which the downstream interface list contains all the interfaces
connected to PIM neighbors, except the interface connected to the upstream router. The router
then forwards subsequent multicast packets through each downstream interface.
When the multicast packets reach a leaf router, the leaf router processes the packets as
follows:
l If the network segment connected to the leaf router has group members, the leaf router
adds its interface that is connected to the network segment to the downstream interface
list of the (S, G) entry, and forwards subsequent multicast packets to the group members.
l If the network segment connected to the leaf router has no group member and the leaf
router does not need to forward multicast packets to downstream PIM neighbors, the leaf
router initiates the prune mechanism and stops forwarding.
Multicast packets are sometimes flooded to a shared network segment with multiple PIM routers. If the
packets pass the RPF check on these PIM routers, multiple copies of multicast packets are forwarded to
this network segment. These PIM routers will need to initiate the assert mechanism.
As shown in Figure 3-2, RouterA, RouterB, and RouterC on the PIM-DM network establish
PIM neighbor relationships by exchanging Hello messages. HostA joins multicast group G
using Internet Group Management Protocol (IGMP) that runs between RouterA and HostA,
but HostB does not join any multicast group.
Figure 3-2 Flooding diagram
Source RouterC RouterA Receiver
HostA
PIM-DM
HostB
RouterB
Multicast packets
Flooding
The flooding process is as follows:
1. Multicast source S sends a multicast packet to multicast group G.

2. RouterC receives the multicast packet and performs the RPF check based on the unicast
routing table. If the packet passes the RPF check, RouterC creates an (S, G) entry, in
which the downstream interface list contains interfaces connected to RouterA and
RouterB. RouterC then forwards subsequent packets to RouterA and RouterB.
3. RouterA receives the multicast packet from RouterC. The packet passes the RPF check,
and RouterA creates an (S, G) entry, in which the downstream interface list contains the
interface connected to HostA. RouterA then forwards subsequent packets to HostA.

4. RouterB receives the multicast packet from RouterC. Because the downstream network
segment does not have group members or PIM neighbors, RouterB sends a Prune
message to RouterC.
Prune
When a PIM router receives a multicast packet, it performs the RPF check o n the packet. If
the packet passes the RPF check but the downstream network segment does not need to
receive the multicast packet, the PIM router sends a Prune message to an upstream router.
After receiving the Prune message, the upstream router deletes the downstream interface from
the downstream interface list of the created (S, G) entry and no longer forwards multicast
packets to the downstream interface. A leaf router initiates the prune mechanism, and the
Prune message is sent upstream by hop along the MDT to prune the network segment that has
no group members.
A PIM router starts a prune timer for the pruned downstream interface. The interface resumes
forwarding multicast packets after the timer expires. Subsequently, multicast packets are
flooded throughout the entire network and new group members can receive multicast packets.
If a leaf router connecting to a network segment that has no group members receives the
flooded multicast packets, the leaf router initiates the prune mechanism. PIM-DM updates the
SPT periodically through the process of periodic flooding and prune.
After a downstream interface of a leaf router is pruned, the leaf router will initiate either the
graft or state refresh mechanism:
l Graft: When new members join a multicast group on the network segment connected to
the leaf router and want to receive multicast packets before the prune timer expires, the
leaf router initiates the graft mechanism.
l State Refresh: When no member joins a multicast group on the network segment
connected to the leaf router and the downstream interface is expected to remain
suppressed, the leaf router initiates the state refresh mechanism.
As shown in Figure 3-3, no group member connects to RouterB, so RouterB sends a Prune
message to the upstream router.
Figure 3-3 Prune diagram
HostA
PIM-DM
HostB
RouterB
Multicast packets
Prune
The prune process is as follows:

1. RouterB sends a Prune message to RouterC, instructing RouterC not to forward data to
the network segment (HostB) to which RouterB connects.
2. After receiving the Prune message, RouterC stops forwarding data through its
downstream interface connecting to RouterB, and deletes this downstream interface from
the (S, G) entry. The prune process for this network segment ends. RouterC sends
subsequent multicast packets only to RouterA, which then forwards the packets to
connected group members (such as HostA).
Graft
PIM-DM uses the graft mechanism to enable new group members on a pruned network
segment to rapidly obtain multicast data. IGMP helps a leaf router learn whether new group
members have joined a multicast group on the connected network segment. If a leaf router
learns that new group members have joined multicast group G, the leaf router sends a Graft
message to the upstream router. The message requests the upstream router to resume multicast
packet forwarding on the downstream interface and to add the downstream interface to the
downstream interface list of the (S, G) entry.
The graft mechanism is initiated by a leaf router and ends at the upstream router receives the
multicast packets.
After the prune process ends, RouterC does not send multicast packets to RouterB before the
next flood-prune process. As shown in Figure 3-4, when HostB joins multicast group G,
RouterB initiates the graft mechanism.
Figure 3-4 Graft diagram
HostA
PIM-DM
Receiver
HostB
RouterB
Multicast packets
Graft
The graft process is as follows:
1. RouterB wants to resume packet forwarding to HostB before the next flood-prune
process, so it sends a Graft message to RouterC. The message requires RouterC to
resume multicast packet forwarding on the downstream interface connecting to RouterB.
2. After receiving the Graft message, RouterC resumes multicast packet forwarding on the
interface and adds the interface to the downstream interface list of the (S, G) entry. The
graft process for RouterB ends. RouterC sends subsequent multicast packets to RouterB,
which then forwards the packets to HostB.

State Refresh
To prevent a pruned interface from resuming multicast packet forwarding after the prune
timer expires, the first-hop router nearest to the multicast source periodically sends a State-
Refresh message throughout the entire PIM-DM network. PIM routers receiving the State-
Refresh message refresh the prune timer state. If no group member joins a multicast group on
the network segment connected to a leaf router in a pruned branch, the upstream interface
connected to this router remains suppressed.
In Figure 3-5, RouterC's interface connected to RouterB is pruned, and no group member
joins a multicast group on the network segment connected to RouterB.
Figure 3-5 State refresh diagram
Source RouterA Receiver
HostA
RouterC PIM-DM
HostB
RouterB
Multicast packets
State Refresh
The state refresh process is as follows:

1. RouterC initiates the state refresh mechanism and sends a State-Refresh message to
RouterA and RouterB.
2. RouterC has a pruned interface and refreshes the prune timer state of this interface.
When RouterC starts new flooding and prune, the pruned interface on RouterC is still
prohibited from forwarding multicast packets because no group member connects to
RouterB.
Assert
When multicast packets pass the RPF check on multiple PIM routers connecting to a network
segment, the assert mechanism is required to ensure that only one PIM router forwards the
multicast packets to the network segment. When a PIM router receives a multicast packet that
is the same as the multicast packet it sends to other neighbors, the PIM router sends an Assert
message with the destination address 224.0.0.13 to all other PIM routers on the same network
segment. When the other PIM routers receive the Assert message, they compare their
parameters with those carried in the Assert message for assert election. The election rules are
as follows:
1. If these routers have different unicast routing priorities, the router with the highest
unicast routing priority wins.
2. If these routers have the same unicast routing priority, the router with the smallest route
cost to the multicast source wins.

3. If these routers have the same unicast routing priority and the same route cost to the
multicast source, the router with the highest IP address for the downstream interface
wins.
A PIM router performs the following operations based on assert election results:
l If a router wins the assert election, its downstream interface becomes the assert winner
and is responsible for forwarding multicast packets to the shared network segment.
l If a router fails the assert election, its downstream interface becomes the assert loser, is
prohibited from forwarding multicast packets to the shared network segment, and is
deleted from the downstream interface list of the (S, G) entry.
After the assert election is complete, only one downstream interface exists on the shared
network segment and it transmits only one copy of multicast packets. All assert losers can
periodically resume multicast packet forwarding, which causes periodic assert elections.
As shown in Figure 3-6, RouterB and RouterC receive multicast packets from the multicast
source. The multicast packets from RouterA pass the RPF check on RouterB and RouterC,
RouterB and RouterC create (S, G) entries and send multicast packets to the same network
segment that their downstream interfaces connect to.
Figure 3-6 Assert diagram
Ethernet
Receiver
Source HostA
RouterB
RouterC
RouterA RouterD
Multicast packets
Assert message from RouterB
Assert message from RouterC
The assert process is as follows:
1. RouterB and RouterC receive a multicast packet from each other through a downstream
interface, but this packet fails the RPF check and is discarded. Then, RouterB and
RouterC send an Assert message to the network segment.
2. RouterB compares its routing information with that carried in the Assert message sent by
RouterC, and it wins the assert election because its route cost to the multicast source is
lower than that of RouterC. RouterB then continues to forward subsequent multicast
packets to the network segment, whereas RouterC discards subsequent multicast packets
because these packets fail the RPF check.
3. RouterC compares its routing information with that carried in the Assert message sent by
RouterB, and it fails the assert election because its route cost to the multicast source is
higher than that of RouterB. RouterC then prohibits its downstream interface from

forwarding multicast packets to the network segment and deletes the interface from the
3.2.3 PIM-SM (ASM Model)
Implementation
In Any-Source Multicast (ASM) implementation, PIM-Sparse Mode (PIM-SM) forwards
multicast packets in pull mode and is for use on large-scale networks with sparsely distributed
group members. Devices on the PIM-SM network work as follows:
l A Rendezvous Point (RP), an important PIM router, is available to provide services for
group members or multicast sources that appear anytime. All PIM routers on the network
know the position of the RP.
l When a new group member appears on the network (that is, a user host joins a multicast
group G through IGMP), the last-hop router 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.
l When an active multicast source appears on the network (that is, the multicast source
sends the first multicast packet to a multicast group G), the first-hop router encapsulates
the multicast data in a Register message and sends the Register message to the RP in
unicast mode. The RP then creates an (S, G) entry and registers multicast source
information.
PIM-SM uses the following mechanisms in the ASM model: neighbor discovery, DR election,
RP discovery, RPT setup, multicast source registration, SPT switchover, and assertion. You
can also configure a Bootstrap router (BSR) to implement fine-grained management in a
single PIM-SM domain. For details about all of these mechanisms, see the sections below.
Neighbor Discovery
PIM routers send Hello messages through PIM-enabled interfaces. In a Hello message:
l The destination address is 224.0.0.13 and all PIM routers on the same network segment
will receive this Hello message.
l The source address is the IP address of the interface that sends multicast packets.
l The time to live (TTL) value is 1.
Hello messages are used to discover PIM neighbors, adjust various PIM protocol parameters,
and maintain neighbor relationships.
l Discovering PIM neighbors

PIM routers on the same network segment must receive multicast packets with the
destination address 224.0.0.13. By exchanging Hello messages, directly connected PIM
routers learn neighbor information and establish neighbor relationships.
A PIM router can receive other PIM messages to create multicast routing entries only
after it establishes neighbor relationships with other PIM routers.
l Adjusting PIM protocol parameters
A Hello message carries the following PIM protocol parameters:
– DR_Priority: indicates the priority used by router interfaces to elect the designated
router (DR). The interface with the highest priority becomes the DR.

– Holdtime: indicates the period during which a neighbor remains reachable. If a

router receives no Hello message from a neighbor within this period, the router
considers that the neighbor is unreachable.
– LAN_Delay: indicates the delay in transmitting Prune messages on a shared
network segment.
– Override-Interval: indicates the interval for overriding the prune mechanism.
l Maintaining neighbor relationships
PIM routers periodically send Hello messages to each other. If a PIM router does not
receive a new Hello message from its PIM neighbor within the holdtime, the router
considers the neighbor unreachable and deletes the neighbor from the neighbor list.
Changes of PIM neighbors lead to multicast topology changes on the network. If an
upstream or downstream neighbor in the MDT is unreachable, multicast routes re-
converge and the MDT is re-established.
DR Election
The network segment where a multicast source or group member resides is usually connected
to multiple PIM routers. These PIM routers exchange Hello messages to set up PIM neighbor
relationships. The Hello messages carry the DR priority and the interface address of the
network segment. Each PIM router compares its own information with the information carried
in the messages sent by its neighbors. A DR is then elected for multicast data forwarding on
the source side or the receiver side. The election rules are as follows:
l If all PIM routers on the network segment allow Hello messages to carry DR priorities,
the PIM router with the highest DR priority is elected as the DR.
l If PIM routers have the same DR priority or at least one PIM router does not allow Hello
messages to carry the DR priority, the PIM router with the largest IP address is elected as
the DR.
If an existing DR becomes faulty, PIM neighbor relationships time out, and a new DR election
is triggered among PIM neighbors.
As shown in Figure 3-7, there are two types of DRs in the ASM model:
l Source DR: DR connected to the multicast source. On the shared network segment
connected to the multicast source, the source DR is responsible for sending Register
messages to the RP.
l Receiver DR: DR connected to group members. On the shared network segment
connected to group members, the receiver DR is responsible for sending Join messages
to the RP and forwarding multicast data to receivers.

Figure 3-7 DR election
Ethernet
Ethernet
Receiver
Source
DR RP
DR
HostA
Server
HostB
Hello
Join
Register
RP Discovery
An RP is responsible for processing Register messages from the multicast source and Join
messages from group members. All PIM routers on the network know the position of the RP.
An RP can serve multiple multicast groups simultaneously, but each multicast group can be
associated with only one RP. RPs can be configured statically or elected dynamically:
l Static RP: All the PIM routers on the network are manually configured with the same RP
address.
l Dynamic RP: Several PIM routers in the PIM domain are configured as Candidate-RPs
(C-RPs) and an RP is elected from the candidates. One or more PIM routers are
configured as Candidate-BSRs (C-BSRs). The C-BSRs automatically elect a BSR, and
this BSR is responsible for collecting and advertising C-RP information.
During a BSR election, each C-BSR considers itself the BSR and sends the entire
network a BootStrap message that carries its address and priority. Each PIM router
compares the Bootstrap messages it receives from the C-BSRs. The BSR is elected based
on the result of the comparison:
– If the C-BSRs have different priorities, the C-BSR with the highest priority (largest
priority value) is elected as the BSR.
– If the C-BSRs have the same priority, the C-BSR with the largest IP address is
elected as the BSR.
Figure 3-8 shows the C-RP election process:
a. C-RPs send Advertisement messages to the BSR. An Advertisement message
carries the address of the C-RP, the range of the multicast groups that it serves, and
its priority.
b. The BSR collects the information in an RP-Set, encapsulates the RP-Set in a
Bootstrap message, and advertises the message to each PIM-SM router on the
network.
c. The routers elect an RP from multiple C-RPs that serve a specific multicast group
based on the RP-set and the following election rules:

n The C-RP with the longest mask length of the served group address range
matching the multicast group that users have joined wins.
n If the mask length is the same, the C-RP with the highest priority (smallest
priority value) wins.
n If the priority is the same, C-RPs use a hash algorithm to calculate their hash
values, and the C-RP with the largest hash value wins.
n If all the preceding values are the same, the C-RP with the largest IP address
wins.
d. PIM routers save the relationship between this multicast group and its RP for
subsequent multicast operations. This relationship is the same on all PIM routers
because they use the same RP-Set and the same election rules.
Figure 3-8 Dynamic RP election
PIM-SM
BSR
C-RP
C-RP
Bootstrap
C-RP advertisement

RPT Setup
Figure 3-9 RPT setup
RouterD Receiver
DR HostA
Source RouterA RouterB RouterC
DR RP
PIM-SM Receiver
DR HostB
(*,G) Join
RouterE
A PIM-SM RPT is a multicast distribution tree (MDT) that uses an RP as the root and group
member routers as leaves. As shown in Figure 3-9, when a group member appears on the
network (that is, a user host joins a multicast group G through IGMP), the receiver DR 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.
During RPT setup, PIM routers perform RPF check before sending a Join message. Each
router searches for a unicast route toward the RP, in which the outbound interface is the
upstream interface and the next hop is the RFP neighbor. Join messages are forwarded from
the receiver DR to the RP hop by hop along the unicast route.
Multicast Source Registration
Figure 3-10 Multicast source registration
RouterD Receiver
DR HostA
Source RouterA RouterB RouterC
DR RP
PIM-SM Receiver
DR HostB
Multicast packets RouterE
Register

As shown in Figure 3-10, a new multicast source on the PIM-SM network must register with
the RP so that the RP can forward multicast data to group members. The registration and
forwarding process is as follows:
1. The multicast source sends a multicast packet to the source DR.

2. After receiving the multicast packet, the source DR encapsulates the multicast packet
into a Register message and sends the Register message to the RP.
3. After receiving the Register message, the RP decapsulates it, creates an (S, G) entry, and
sends multicast data to group members along the RPT.
SPT Switchover
A multicast group on a PIM-SM network can be associated with only one RP and sets up only
one RPT. Under normal circumstances, all multicast packets destined for a multicast group are
encapsulated in Register messages and sent to the RP. The RP then decapsulates the packets
and forwards them along the RPT to multicast group members. All multicast packets pass
through the RP. If the number of multicast packets increases dramatically, the RP becomes
heavily burdened. To resolve this problem, PIM-SM allows the RP or the receiver DR to
trigger an SPT switchover.
l SPT switchover triggered by the RP

After receiving a Register message from the source DR, the RP decapsulates the Register
message and forwards multicast packets along the RPT to group members. The RP also
sends a Join message to the source DR to set up an SPT from the RP to the source.
After the SPT is set up, the source DR forwards multicast packets directly to the RP.
After the switchover, the source DR and RP do not need to encapsulate or decapsulate
packets.
l SPT switchover triggered by the receiver DR
Figure 3-11 SPT switchover triggered by the receiver DR
Source RouterA RouterB

DR RP
DR
RouterC RouterD Receiver

HostA
Multicast packets
(S,G) Join
(S,G) Prune

As shown in Figure 3-11, the receiver DR periodically checks the forwarding rate of
multicast packets. When the receiver DR finds that the forwarding rate is higher than a
configured threshold, it triggers an SPT switchover.
a. The receiver DR sends a Join message to the source DR hop by hop, creates an (S,
G) entry hop by hop, and then sets up an SPT from the source DR to the receiver
DR.
b. After the SPT is set up, the receiver DR sends Prune messages along the RPT to the
RP, which then deletes the downstream interface connected to the receiver DR from
the (*, G) entry. After the prune action is complete, the RP no longer forward
multicast packets along the RPT.
c. Because the SPT does not pass through the RP, the RP continues to send Prune
messages along the RPT to the source DR, which then deletes the downstream
interface connected to the RP from the (S, G) entry. After the prune action is
complete, the source DR no longer forward multicast packets along the SPT to the
RP.
By default, no threshold for the multicast packet forwarding rate is configured on the device. Therefore,
an SPT switchover is triggered when the RP or receiver DR receives the first multicast packet from the
multicast source.
Assert
When multicast packets pass the RPF check on multiple PIM routers connecting to a network
segment, the assert mechanism is required to ensure that only one PIM router forwards the
multicast packets to the network segment.
When a PIM router receives a multicast packet that is the same as the multicast packet it sends
to other neighbors, the PIM router broadcasts an Assert message with the destination address
224.0.0.13 to all other PIM routers on the same network segment.
When the other PIM routers receive the Assert message, they compare their parameters with
those carried in the Assert message for assert election. The election rules are as follows:
1. If these routers have different priorities, the router with the highest unicast routing
priority wins.
2. If these routers have the same unicast routing priority, the router with the smallest route
cost to the multicast source wins.
3. If these routers have the same unicast routing priority and the same route cost to the
multicast source, the router with the highest IP address for the downstream interface
wins.
A PIM router performs the following operations based on assert election results:
l If a router wins the assert election, its downstream interface becomes the assert winner
and is responsible for forwarding multicast packets to the shared network segment.
l If a router fails the assert election, its downstream interface becomes the assert loser, is
prohibited from forwarding multicast packets to the shared network segment, and is
deleted from the downstream interface list of the (S, G) entry.
After the assert election is complete, only one downstream interface exists on the shared
network segment and it transmits only one copy of multicast packets. All assert losers can
periodically resume multicast packet forwarding, which causes periodic assert elections.

As shown in Figure 3-12, RouterB and RouterC receive multicast packets from the multicast
source. The multicast packets from RouterA pass the RPF check on RouterB and RouterC,
RouterB and RouterC create (S, G) entries and send multicast packets to the same network
segment that their downstream interfaces connect to.
Figure 3-12 Assert diagram
Ethernet
Receiver
Source HostA
RouterB
RouterC
RouterA RouterD
Multicast packets
Assert message from RouterB
Assert message from RouterC
The assert process is as follows:

1. RouterB and RouterC receive a multicast packet from each other through a downstream
interface, but this packet fails the RPF check and is discarded. Then, RouterB and
RouterC send an Assert message to the network segment.
2. RouterB compares its routing information with that carried in the Assert message sent by
RouterC, and it wins the assert election because its route cost to the multicast source is
lower than that of RouterC. RouterB then continues to forward subsequent multicast
packets to the network segment, whereas RouterC discards subsequent multicast packets
because these packets fail the RPF check.
3. RouterC compares its routing information with that carried in the Assert message sent by
RouterB, and it fails the assert election because its route cost to the multicast source is
higher than that of RouterB. RouterC then prohibits its downstream interface from
forwarding multicast packets to the network segment and deletes the interface from the
BSR Administrative Domain

To provide fine-grained network management, a PIM-SM network has both a global domain
and multiple BSR administrative domains. This reduces the workload on individual BSRs and
allows provisioning of special services to users in a specific domain by using private group
addresses.
Each BSR administrative domain maintains only one BSR that serves multicast groups within
a specific group address range. The global domain maintains a BSR that serves multicast
groups not served by an administrative domain.
This section describes the relationship between BSR administrative domains and the global
domain in terms of domain space, group address ranges, and multicast functions.

l Domain space
Figure 3-13 Relationship between BSR administrative domains and the global domain
from in terms of domain space
C-RP BSR
BSR1 domain
BSR C-RP
Global domain C-RP
C-RP BSR
BSR2 domain
As shown in Figure 3-13, BSR administrative domains for the same group address
contain different PIM routers. A PIM router belongs to only one BSR administrative
domain. BSR administrative domains are independent of and isolated from each other.
Each BSR administrative domain manages the multicast groups within a specific group
address range. Multicast packets within this range can be transmitted only within this
administrative domain and cannot cross its border.
The global domain contains all PIM routers on the PIM-SM network. A multicast packet
that does not belong to any BSR administrative domain can be transmitted throughout
the entire PIM network.
l Group address range
Figure 3-14 Relationship between BSR administrative domains and the global domain in
terms of group address ranges
BSR1 BSR3
G1 address G3 address
Global
G-G1-G2 address BSR2
G2 address

Each BSR administrative domain provides services for multicast groups within a specific
group address range. The group address ranges served by different BSR administrative
domains can overlap. As shown in Figure 3-14, the group address range of BSR1
overlaps that of the BSR3. The address of a multicast group that a BSR administrative
domain serves is used as a private group address and is valid only in its BSR
administrative domain.
The global domain serves all multicast groups that do not belong to a BSR
administrative domain. As shown in Figure 3-14, the group address range of the global
domain is G-G1-G2.
l Multicast function
As shown in Figure 3-13, the global domain and each BSR administrative domain have
their respective C-RP and BSR devices. These devices function only in the domain
where they reside. Each domain holds independent BSR and RP elections.
Each BSR administrative domain has a border. Multicast messages from this domain,
such as C-RP Advertisement messages or BSR BootStrap messages, can be transmitted
only within the domain where they originate. Multicast messages from the global domain
can be transmitted throughout the entire global domain and traverse any BSR
administrative domain.
3.2.4 PIM-SM (SSM Model)
Implementation
Source-Specific Multicast (SSM) model uses IGMPv3/MLDv2 and PIM-SM technology.
There is no need to maintain an RP, set up an RPT, or register a multicast source. An SPT can
be built directly between the source and group members.
In the SSM model, user hosts know the positions of multicast sources in advance of
requesting multicast services. When user hosts join multicast groups, they can specify the
sources from which they want to receive data. After receiving requests from user hosts, the
receiver DR sends a Join message to the source DR. The Join message is then transmitted
upstream hop by hop to set up an SPT between the source and group members.
In the SSM model, PIM-SM uses the following mechanisms: neighbor discovery, DR
election, and SPT setup. For details about all of these three mechanisms, see the sections
below.
Neighbor Discovery
Neighbor discovery in PIM-SM (SSM model) is similar to that in PIM-SM (ASM model). For
details, see "PIM-SM (ASM model) Neighbor Discovery".
DR Election
DR election in PIM-SM (SSM model) is similar to that in PIM-SM (ASM model). For details,
see "PIM-SM (ASM model) DR Election".

SPT Setup
Figure 3-15 SPT setup
Source RouterD Receiver
S1 RouterA DR DR HostA
Source RouterB RouterC
S2 DR
PIM-SM Receiver
Multicast packets
(S1,G) Join DR
RouterE HostB
(S2,G) Join
Figure 3-15 shows the SPT setup process:

1. Using IGMPv3/MLDv2, RouterD and RouterE learn that packets from user hosts have
the same multicast group address but are requesting multicast data from different source
addresses. They send Join messages to sources hop by hop.
2. PIM routers create (S1, G) and (S2, G) entries based on the Join messages and set up
SPTs from S1 to HostA and from S2 to HostB.
3. After SPTs are set up, the sources forward multicast packets along the SPTs to group
members.
Comparison with the ASM Model

The major difference between the SSM and ASM models is that the SSM model allows hosts
to specify desired multicast sources and the ASM does not. Table 3-1 describes differences of
the two models.
Table 3-1 Comparisons between PIM implementations

Protocol Model Usage Scenario Implementation
An MDT is set up
when receivers join
PIM-SM
Large-scale network a multicast group.
(Protocol
where multicast PIM-SM needs to
Independent ASM model
group members are maintain an RP, set
Multicast-Sparse
distributed sparsely up an RPT, and
Mode)
register a multicast
source.

Protocol Model Usage Scenario Implementation
Scenarios where
user hosts know the
exact positions of
PIM-SSM does not
multicast sources in
need to maintain an
advance and can
SSM model RP, set up an RPT,
specify the sources
or register a
from which they
multicast source.
want to receive data
before they join
multicast groups
3.2.5 Bidir-PIM
Implementation
In some multicast applications, such as multi-party video conferencing and online gaming, a
user host not only receives multicast data as a receiver, but also sends multicast data to other
user hosts as a multicast source. In such a scenario with many multicast sources, if PIM-SM is
used to set up shortest path trees (SPTs) for multicast data forwarding, multicast routers must
create an (S, G) entry for each multicast source. That is, a multicast group requires a multicast
distribution tree for each multicast source. A lot of forwarding resources are consumed to
maintain the (S, G) entries, placing heavy burden on the routers.
By all multicast sources for a group sharing the same multicast distribution tree, Bidirectional
PIM (Bidir-PIM) can reduce loads on multicast routers. Bidir-PIM sets up a bidirectional
rendezvous point tree (RPT) rooted at an RP. Multicast data is forwarded from multicast
sources to receivers along the bidirectional RPT. The bidirectional RPT is set up based on (*,
G) entries, which means that the multicast distribution tree is built according to the groups
while the sources are not in consideration. Routers do not need to maintain a lot of (S, G)
entries, consuming much fewer forwarding resources.
Key mechanisms used in Bidir-PIM include neighbor discovery, RP discovery, designated
forwarder (DF) election, and bidirectional RPT setup. Bootstrap router (BSR) administrative
domains can be configured to implement refined management in a Bidir-PIM domain.
The following sections describe these mechanisms based on the Bidir-PIM network shown in
Figure 3-16.

Figure 3-16 Bidir-PIM network

Receiver1 Source2
HostA Server
RouterB
RouterA
RouterD RouterE
RouterC
Bidir-PIM
network
RouterG
HostB
HostC RouterF Source4/Receiver4
Source3/Receiver3
Neighbor Discovery
Like routers on PIM-SM networks, routers on a Bidir-PIM network also exchange PIM Hello
messages to maintain neighbor relationships and adjust control parameters for PIM protocol
packets. Bidir-PIM adds the Bidirectional Capable PIM-Hello option in PIM Hello messages
sent from Bidir-PIM-capable routers.
Routers in Figure 3-16 exchange PIM Hello messages with the Bidirectional Capable PIM-
Hello option to set up neighbor relationships and learn the Bidir-PIM capabilities of their
neighbors.
For details about the neighbor discovery mechanism, see "PIM-SM (ASM model) Neighbor
Discovery".
RP Discovery
The RP discovery mechanism on a Bidir-PIM network is similar to that on a PIM-SM
network. All routers obtain RP information after static or dynamic RP configuration is
complete. The difference is that Bidir-PIM supports RP election for a multicast group that
users have joined based on modulo of the group address and the number of C-RPs. This RP
election method can evenly distribute multicast groups to multiple RPs to avoid congestion
caused by uneven bandwidth allocation on the Bidir-PIM network. On a Bidir-PIM network,
C-RPs select the RP for a multicast group that users have joined according to the following
rules:
l The C-RP with the longest mask length of the served group address range matching the
multicast group that users have joined wins.
l If the mask length is the same, the C-RP with the highest priority (smallest priority
value) wins.
l If the priority is the same, the RP is elected using either of the following rules:
– C-RPs use the group address that users have joined, C-RP addresses, and C-RP
address masks to calculate hash values. The C-RP with the largest hash value
becomes the RP that serves the multicast group. This is the default RP election

method used on a device, but it cannot evenly distribute multicast groups to RPs
and therefore may cause congestion on the multicast network.
– C-RPs select the RP based on the modulo of the group address that users have
joined and the number of C-RPs. This RP election method can evenly distribute
multicast groups to RRs to avoid congestion on the multicast network. It is only
applicable to networks with multiple C-RPs serving contiguous multicast group
addresses.
This RP election method is applicable to IPv4 Bidir-PIM networks but not IPv6
Bidir-PIM networks.
l If all the preceding values are the same, the C-RP with the largest IP address wins.
The RP must be configured to serve Bidir-PIM, regardless which configuration method is
used.
Bidir-PIM allows a nonexistent rendezvous point address (RPA). That is, the RPA may not be
an interface IP address on any router. The network segment to which the RPA belongs is the
rendezvous point link (RPL). The RPL must be an existing link connected to a router. Any
interface on the RPL can function as the RP interface, and the interfaces back up one other.
In the following description, RPA refers to an RP. An RPA is the transit for multicast data, so
it is usually deployed on a link where multicast streams aggregate. In Figure 3-17, the
network segment 10.1.1.0/24 connected to RouterA and RouterB is selected as the RPL, and
an IP address on this network segment is configured as the RPA. Then the interfaces on
RouterA and RouterB connected to each other can be used as RP interfaces and back up each
other.
Figure 3-17 Configure an RPA
RPA:10.1.1.3/24
Receiver1 Source2
HostA RouterA RouterB Server
RPL:10.1.1.0/24
RouterC RouterD RouterE
Bidir-PIM
network
RouterG
HostC HostB
RouterF
Source3/Receiver3 Source4/Receiver4
RP interface

For details about the RP discovery mechanism, see "PIM-SM (ASM model) RP
Discovery".
DF Election
A DF plays an important role on a Bidir-PIM network. It forwards all multicast data on the
local network segment, and sends PIM Join messages to the RPA based on requirements of
user hosts on the local network segment to set up a bidirectional RPT between the RPA and
user hosts.
On the entire network, for an RPA, each network segment except the RPL must have a DF
elected.
RouterC, RouterD, and RouterF on a shared network segment in Figure 3-16 are used as an
example to describe how a DF is elected.
1. Initial DF election
Once a router obtains RPA information, it triggers a DF election for the RPA on the local
network segment by sending multicast Offer messages to the other routers on this network
segment. Each Offer message contains the preference and metric of the route from the local
router to the RPA. The DF election rules are as follows:
1. The router with the highest route preference to the RPA wins.
2. If routers have the same route preference, the one with the smallest route metric to the
RPA wins.
3. If routers have the same route metric to the RPA, the one with the largest interface IP
address wins.
On the network shown in Figure 3-16, RouterF has not connected to the local network
segment, and RouterC has a smaller route metric to the RPA than RouterD. After RouterC and
RouterD obtain RPA information in turn, they start the DF election. Figure 3-18 shows the
DF election process.
Figure 3-18 Initial DF election process

RouterC RouterD
1. Send an Offer message
2. Enter Offer suppression

state
3. Send more Offer
messages
4. Send a Win message
5. Enter Lose state and

record DF information
1. RouterC sends an Offer message to the local network segment and starts a timer. The
timer value is set to Offer_Period (OP) to control the interval between Offer messages.

2. RouterD receives the Offer message and finds that the RouterC's route metric to the RPA
is smaller than its own metric. Then RouterD enters the offer suppression state and starts
a timer, with the timer value set to the product of OP and DF Election_Robustness (ER).
During the suppression period, RouterD does not send Offer messages to the local
network segment.
3. RouterC sends an Offer message every time the timer expires, for ER times.
4. If RouterC does not receive any Offer message from other routers after sending Offer
messages ER times, it considers itself the best router on the local network segment. Then
RouterC stops the timer and sends Win messages to the local network segment to
announce itself as the DF.
5. When RouterD receives a Win message, it records DF information in the Win message
and enters the Lose state.
2. DF election upon a network topology change
After the initial DF election, RouterC becomes the DF on the shared network segment. DF
elections are not performed periodically, and RouterC retains the DF role as long as the
network topology remains unchanged. When the network topology changes, different DF
election processes are triggered in different conditions as follows:
l The Loser's route metric to the RPA changes: RouterD's route metric to the RPA
becomes smaller than that of RouterC.
RouterC RouterD

2. Send a Backoff
message
3. Enter Offer
suppression state
4. Send a Pass message
5. Enter Win state
a. RouterD compares recorded DF information with its own information and finds that
its own route metric is smaller than the DF's route metric to the RPA. Therefore,
RouterD sends an Offer message to the local network segment and starts a timer,
with the timer value set to OP.
b. When RouterC receives the Offer message, it knows that RouterD has a smaller
route metric to the RPA. Then it sends a Backoff message to the local network
segment to announce that a router with a better route to the RPA is available. At the
same time, RouterC starts a timer and sets the timer value to Backoff_Period (BP)
to control the interval between Backoff messages.
c. When RouterD receives the Backoff message, it finds that the message carries its
own information. RouterD then enters the Offer suppression state and resets its
timer to BP + OP.

d. When the timer of RouterC times out, RouterC sends a Pass message to announce
RouterD as the new DF. Meanwhile, RouterC enters the Lose state and records the
new DF information.
e. When RouterD receives the Pass message, it stops its timer, enters the Win state,
and becomes the new DF.
l The DF's route metric to the RPA changes: RouterC's route metric to the RPA becomes
larger than that of RouterD.
RouterC RouterD

3. Send a Backoff
message
4. Enter Offer
suppression state
5. Send a Pass message
6. Enter Win state
a. When RouterC finds that its route metric to the RPA increases, it sends a Win
message to the local network segment.
b. When RouterD receives the Win message, it finds that its own route metric is
smaller and sends an Offer message to the local network segment. The subsequent
process is the same as that occurs when the Loser's route metric to the RPA
changes.
l The DF loses the route to the RPA: RouterC has no reachable route to the RPA.
RouterC RouterD
3. Enter Offer suppression

state
4. Send more Offer
messages

a. RouterC no longer works as the DF and sends an Offer message with an infinite
metric value to the RPA.

b. When RouterD receives the Offer message, it finds that its own route metric is
smaller and sends an Offer message to the local network segment. The subsequent
process is the same as the initial DF election process.
l A new router appears: RouterF joins the local network segment and has a larger route
metric to the RPA than RouterC and RouterD.
RouterF RouterC RouterD
1. Send an Offer
message
1. Send an Offer message 2. Enter Offer suppression
state
record DF information 5. Enter Lose state and
a. RouterF sends an Offer message to the local network segment.

b. When RouterD receives the Offer message, it finds that its own route metric to the
RPA is smaller. Then RouterD enters the suppression state and starts a timer, with
the timer value set to OP. In suppression state, RouterD waits for the message sent
by the DF in response to RouterF's Offer message and does not send Offer
messages.
c. When RouterC receives the Offer message, it finds that is own route metric to the
RPA is smaller and sends a Win message to the local network segment.
d. When RouterF receives the Win message, it enters the Lose state and records DF
information.
e. When RouterD receives the Win message, it enters the Lose state and records DF
information.
l The DF stops working: RouterC fails.
RouterC RouterD
1. Send an Offer
message
2. Send more Offer
messages

RouterD receives no PIM Hello message from RouterC in a long time and considers that
its PIM neighbor has failed. It then sends an Offer message to the local network segment.
The subsequent DF election process is the same as the initial DF election process.
Bidirectional RPT Setup

A bidirectional RPT forwards multicast data bidirectionally. When a host requests data sent to
multicast group G, the routers connected to the host send PIM Join messages hop by hop
toward the RPA. Based on the PIM Join messages, the routers create (*, G) entries to set up an
RPT. The RPT setup process stops on the RPL. The Bidir-PIM protocol considers the host as
both a receiver and a multicast source for group G. Therefore, the routers add both the DF
interface and the reverse path forwarding (RPF) interface toward the RPA to the outbound
interface list in their (*, G) entries. In this way, a bidirectional RPT is set up based on the (*,
G) entries.
Note that multicast data sent from a multicast source is still forwarded unidirectionally.
Bidirectional mentioned in this section means that multicast data sent from different multicast
sources is forwarded in different directions. When routers on a bidirectional RPT receive a
multicast data packet, they check whether the inbound interface of the packet is the RPF or
DF interface. If so, the routers forward the packet according to the (*, G) entry. If not, they
drop the packet. The routers never forward a multicast data packet to the inbound interface of
the packet, even if the inbound interface is in the outbound interface list of the (*, G) entry.
Therefore, multicast data sent from a host is forwarded unidirectionally on the bidirectional
RPT and will not be sent back to the host.
If multicast data is only sent from multicast sources and hosts only receive multicast data, a
bidirectional RPT cannot be set up. In this case, multicast data sent from multicast sources is
unconditionally forwarded to the RPA by the DF.
The following describes the bidirectional RPT setup and multicast data forwarding processes
for HostA, HostC, and Server on Figure 3-16.
1. Setting up a bidirectional RPT
Figure 3-19 shows the bidirectional RPT setup process triggered by HostC as a receiver,
which is described as follows:
1. HostC sends an IGMP Report message. Interface IF0 of RouterF is the DF on the local
network segment. When IF0 receives the IGMP Report message, RouterF creates a (*,
G) entry and adds IF0 and the RPF interface (IF1) toward the RPA to the outbound
interface list. Meanwhile, RouterF sends a PIM Join message to IF1, which forwards the
PIM Join message to the upstream neighbor, the DF on the network segment connected
to IF1.
2. When RouterC receives the PIM Join message from DF interface IC0, it creates a (*, G)
entry, and adds IC0 and the RPF interface IC1 toward the RPA to the outbound interface
list. Meanwhile, RouterC sends a PIM Join message to IC1, which forwards the PIM
Join message to the upstream neighbor, the DF on the network segment connected to
IC1.
3. When RouterA receives the PIM Join message from DF interface IA1, it creates a (*, G)
entry, and adds IA1, DF interface IA0 on the network segment of HostA, and RPF
interface IA2 toward the RPA to the outbound interface list. The bidirectional RPT setup
process ends on RouterA because RouterA is directly connected to the RPL.
The bidirectional RPT setup process triggered by HostA is similar.

Figure 3-19 Bidirectional RPT setup

Source2
Server
Receiver1
HostA RouterA RPA
IA2
IA0 RPL
IA1 RouterB
RouterD RouterE
IC1
IC0 RouterC
Bidir-PIM
network
IF1
IF0
RouterF
HostC
Source3/Receiver3 DF interface
RPF interface
PIM Join message
Bidirectional RPT
2. Forwarding multicast data

Figure 3-20 illustrates how multicast data sent from Server and HostC to multicast group G is
forwarded on the Bidir-PIM network.

Figure 3-20 Multicast data packet forwarding

Source2
Server
Receiver1
HostA RouterA RouterB
IA1 RPL
IA2 IB1 IB0

IA0
RouterD IE1
IC1 IE0
IC0 RouterC RouterE
Bidir-PIM
IF1 network
IF0
RouterF
HostC
Source3/Receiver3
DF interface
RPF interface
Multicast data packets from Source2
Multicast data packets from Source3
Bidirectional RPT
l Forwarding of multicast data sent from HostC:

a. HostC sends multicast data packets. RouterF receives the multicast data packets
from DF interface IF0 and forwards them to outbound interface IF1 according to the
matching (*, G) entry. RouterF does not forward the multicast data packets to IF0 in
the outbound interface list, because IF0 is the inbound interface of the multicast
data packets.
b. RouterC receives the multicast data packets from DF interface IC0 and forwards
them to outbound interface IC1 according to the matching (*, G) entry. RouterC
does not forward the multicast data packets to IC0 in the outbound interface list,
because IC0 is the inbound interface of the multicast data packets.
c. RouterA receives the multicast data packets from DF interface IA0 and forwards
them to outbound interfaces IA1 and IA2 according to the matching (*, G) entry.
RouterA does not forward the multicast data packets to IA0 in the outbound
interface list, because IA0 is the inbound interface of the multicast data packets.
d. RouterB receives the multicast data packets from interface IB1 and finds no
matching (*, G) entry for the packets. Because the RPF interface IB1 toward the
RPA is the inbound interface of the multicast data packets, RouterB stops
forwarding the multicast data packets.
e. HostA receives the multicast data packets, and multicast data forwarding is
complete.

l Forwarding of multicast data sent from Server:

a. Server sends multicast data packets. RouterE receives the multicast data packets
from DF interface IE0 and finds no matching (*, G) entry for the packets.
Therefore, RouterE forwards the multicast data packets to RPF interface IE1 toward
the RPA.
b. RouterB receives the multicast data packets from DF interface IB0 and finds no
matching (*, G) entry for the packets. Therefore, RouterB forwards the multicast
data packets to RPF interface IB1 toward the RPA.
c. RouterA receives the multicast data packets and forwards them to outbound
interfaces IA0 and IA1 according to the matching (*, G) entry. RouterA does not
forward the multicast data packets to IA2 in the outbound interface list, because
IA2 is the inbound interface of the multicast data packets.
d. HostA receives the multicast data packets.
e. RouterC receives the multicast data packets from RPF interface IC1 and forwards
them to outbound interface IC0 according to the matching (*, G) entry. RouterC
does not forward the multicast data packets to IC1 in the outbound interface list,
because IC1 is the inbound interface of the multicast data packets.
f. RouterF receives the multicast data packets from RPF interface IF1 and forwards
them to outbound interface IF0 according to the matching (*, G) entry. RouterF
does not forward the multicast data packets to IF1 in the outbound interface list,
because IF1 is the inbound interface of the multicast data packets.
g. HostC receives the multicast data packets. Multicast data forwarding is complete.
BSR Administrative Domain

To provide fine-grained network management, a Bidir-PIM network can be divided into a
global domain and multiple BSR administrative domains. This reduces the workload on a
single BSR and allows provisioning of services specific to a domain using private group
addresses.
The BSR administrative domain mechanism on a Bidir-PIM network is the same as that on a
PIM-SM network. For details, see PIM-SM (ASM model) BSR Administrative Domain.
3.2.6 PIM BFD
A network device must detect a communications fault between adjacent devices quickly so
that the upper layer protocol can rectify the fault and prevent a service interruption.
Bidirectional Forwarding Detection (BFD) provides uniform, millisecond-level detection for

all media and protocol layers. Two systems set up a BFD session and periodically send BFD
control packets along the path between them. If one system does not receive BFD control
packets within a specified period, the system considers that a fault has occurred on the path.
Implementation
If the current DR or Assert winner on the shared network segment is faulty in a multicast
scenario, other PIM neighbors start a new DR election or Assert election after the neighbor
relationship or the Assert timer times out. Consequently, multicast data transmission is
interrupted. The interruption period, usually in seconds, is at least as long as the timeout
interval of the neighbor relationship or the Assert timer.

Because PIM BFD detects the link status on a shared network segment within milliseconds, it
responds quickly to PIM neighbor faults. If an interface enabled with PIM BFD does not
receive BFD control packets from the DR or Assert winner within the detection interval, it
considers that the DR or Assert winner is faulty. BFD fast notifies the RM of the session
status and the RM then notifies the PIM module. The PIM module triggers a new DR election
or Assert election without waiting for the neighbor relationship or the Assert timer to expire.
PIM BFD reduces the time services are interrupted and makes data transmission more
reliable.
Figure 3-21 PIM BFD

Ethernet
Ethernet
RouterA
Source Interface1
RouterB
PIM SM Receiver
Interface2 HostA
RouterC
PIM BFD Session
Figure 3-21 shows a shared network segment connected to user hosts. Downstream Interface1
on RouterB and downstream Interface2 on RouterC establish a PIM BFD session and send
BFD control packets to detect link status.
RouterB functions as the DR and its downstream interface Interface1 is responsible for
forwarding multicast data. If Interface1 becomes faulty, BFD fast notifies the RM of the
session status and the RM then notifies the PIM module. The PIM module then triggers a new
DR election. RouterC quickly begins functioning as the new DR and its downstream interface
Interface2 forwards multicast data to the receivers.
3.3 Application Scenarios for PIM
3.3.1 PIM-DM Application in a Single AS
Figure 3-22 shows multicast services deployed on a small-scale network. The Interior
Gateway Protocol (IGP) is running on the network and all network segments are reachable.
Multicast group members are densely distributed. Hosts on this network want to receive video
on demand (VoD) information, and network bandwidth needs to be used efficiently.

Figure 3-22 PIM-DM application in a single AS
Receiver
RouterB HostA
PIM-DM network
Source RouterA RouterC RouterD

Receiver
HostB
Receiver
HostC
RouterE RouterF
Interfaces on which PIM-DM needs to be enabled
Implementation Plan
As shown in Figure 3-22, HostA, HostB, and HostC are receivers of multicast video streams.
The entire PIM domain runs PIM-DM. RouterA connects to the multicast source (Source);
RouterB connects to the network segment of HostA; RouterD and RouterF connect to the
network segment of HostB and HostC.
The network deployment must meet the following requirements:
l PIM-DM is enabled on all router interfaces.
l IGMP runs between the routers and hosts on a shared network segment (between
RouterB and HostA, and between RouterD/RouterF and HostB/HostC).
All router interfaces on the same network segment must run the same IGMP protocol
version (IGMPv2 is recommended) and be configured with the same parameter settings,
such as the query interval and timeout period of group memberships. If IGMP versions
or parameter settings are inconsistent, IGMP group memberships on routers will be
different.
l After the network is deployed, HostA, HostB, and HostC can receive multicast data from
Source, and the users can watch the video programs they request.
It is recommended that members be statically added to a multicast group at the network border.
This improves the stability of multicast services.
3.3.2 PIM-SM Application in a Single AS

Figure 3-23 shows multicast services deployed on a large-scale network. The Interior
Gateway Protocol (IGP) is running on the network and all network segments are reachable.
Multicast group members are sparsely distributed. Hosts on this network want to receive VoD
information, and network bandwidth needs to be used efficiently.

Figure 3-23 PIM-SM application in a single AS
Receiver
S1 RouterA RouterB HostA
S2 RouterC C-BSR C-RP RouterE Receiver

C-RP
HostB
C-BSR
RouterD
PIM-SM network
Receiver
HostC
RouterF RouterG
Interfaces on which PIM-SM needs to be enabled
Implementation Plan
As shown in Figure 3-23, HostA, HostB, and HostC are receivers of multicast video streams.
The entire PIM domain runs PIM-SM. RouterA connects to multicast source S1 and RouterC
connects to multicast source S2. RouterB connects to the network segment of HostA; RouterE
and RouterG connect to the network segment of HostB and HostC.
The network deployment must meet the following requirements:
l PIM-SM is enabled on all router interfaces.

l The core device closest to the multicast source is used as the C-RP because multicast
sources are densely distributed. The interfaces of RouterC and RouterD are configured as
the C-BSR and C-RP. The BSR and RP are elected dynamically.
Recommended RP deployment is as follows:
– On small- and medium-scale networks, a static RP can be used because the static
RP is stable and has low requirements for device configurations.
If there is only one multicast source, a device directly connected to the multicast
source can be used as a static RP so that the source DR does not need to register
with the RP.
If a static RP is deployed, all routers including the RP in the same domain must be
configured with the same RP information and the same range of multicast groups.
– On large-scale networks, a dynamic RP can be used because a dynamic RP is highly
reliable and easy to maintain.
If multiple densely distributed multicast sources exist on the network, a core device
close to the multicast sources is used as the C-RP. If there are multiple densely
distributed group members, a core device close to the group members is used as the
C-RP.

To ensure consistent RP information on all devices in the PIM domain, use the same type of RP
(static or dynamic) on all the devices.
l IGMP runs between the routers and hosts on a shared network segment (between
RouterB and HostA, and between RouterE/RouterG and HostB/HostC).
All router interfaces on the same network segment must run the same IGMP protocol
version and be configured with the same parameter settings, such as the query interval
and timeout period of group memberships. If IGMP versions or parameter settings are
inconsistent, IGMP group memberships on routers will be different.
l After the network is deployed, HostA, HostB, and HostC send Join messages to the RP
based on service requirements, and multicast data sent from the multicast source can
reach the receivers.
It is recommended that members be statically added to a multicast group at the network border.
This improves the stability of multicast services.
3.3.3 Bidir-PIM Application in a Single AS

Figure 3-24 illustrates multicast service deployment on a large-scale network. The Interior
Gateway Protocol (IGP) is running on the network, and all network segments are reachable. A
multicast protocol is required on the network to allow multi-party video conferences among
users connected to the network.
Figure 3-24 Bidir-PIM application in a single AS

HostA HostB
RouterA RouterB
RP
Bidir-PIM
network
RouterE
RouterC RouterD
HostC HostD
Bidirectional RPT

Implementation
As shown in Figure 3-24, HostA, HostB, HostC, and HostD need to join a multi-party video
conference, and the entire PIM domain runs Bidir-PIM.
The network deployment is as follows:
1. Enable Bidir-PIM on all routers in the PIM domain.
2. Enable PIM-SM on all router interfaces so that they can set up PIM neighbor
relationships.
3. Select a router at the meeting point of multicast streams as the RP and configure the RP
to serve Bidir-PIM. For example, RouterE in Figure 3-24 can act as the RP.
Recommended RP deployment is as follows:
– On small and medium networks, configure a static RP because the static RP is
stable and has low requirements on device configurations.
If a static RP is configured, all routers (including the RP) in the domain must be
configured with the same RP information and multicast group range.
– On large networks, deploy dynamic RP to improve reliability and facilitate
maintenance.
Do not use both static and dynamic RP configurations in the same PIM domain because this may
cause inconsistent RP information on routers.
4. Run IGMP between RouterA and HostA, RouterB and HostB, RouterC and HostC, and
RouterD and HostD.
All router interfaces on the same network segment must run the same IGMP version
(IGMPv2 is recommended) and have the same parameter settings, such as the query
intervals and timeout period of group memberships. If router interfaces run different
IGMP versions or use different parameter settings, routers cannot maintain consistent
IGMP group membership.
5. After the configurations are complete, routers on the network set up a bidirectional RPT
rooted at the RP, and the hosts can communicate in a video conference.
To enable user hosts to receive multicast data stably, statically bind the multicast groups requested
by user hosts to the interfaces directly connected to the user network segments.
3.4 Summary of IPv4 PIM Configuration Tasks

After PIM is configured, multicast data can be routed and forwarded on an IPv4 network. PIM
includes multiple modes that apply to different scenarios. Table 3-2 lists IPv4 PIM
configuration tasks.

Table 3-2 IPv4 PIM configuration tasks

Task Description
3.7 Configuring IPv4 PIM-DM The PIM-DM configuration is simple, but

multicast data will be periodically flooded
throughout the network. Therefore, PIM-
DM applies to small-sized networks with
densely distributed receivers.
3.8 Configuring IPv4 PIM-SM PIM-SM uses the ASM and SSM models to
provide multicast services. In the ASM
model, a multicast distribution tree (MDT)
is set up by receivers actively joining the
multicast group. PIM-SM needs to maintain
an RP, set up an RPT, and register multicast
sources. The ASM model applies to the
large network where members are widely
distributed. In the SSM model, PIM-SM
sets up an SPT between a multicast source
and members and does not need to maintain
an RP, set up an RPT, or register multicast
sources. The SSM model applies to the
network where users know multicast source
locations and directly request multicast data
from a specified multicast source.
3.9 Configuring IPv4 Bidir-PIM Bidir-PIM uses the ASM model to provide
multicast services. Similar to the ASM
model of PIM-SM, Bidir-PIM sets up an
MDT by receivers actively joining the
multicast group. Bidir-PIM needs to
maintain an RP and set up an RPT. On a
Bidir-PIM network, the switch connected to
a user network segment does not switch
from the RPT to SPT when receiving
multicast data. The RPT is bidirectional,
saving forwarding resources on the switch
when multiple multicast sources exist.
Bidir-PIM applies to the network where
multiple multicast sources exist, such as
multi-party call or video conferences and
online games.
3.5 Licensing Requirements and Limitations for IPv4 PIM

a multicast source.

IPv4 PIM is a basic software function of the switch. The license for basic software functions
has been loaded and activated before delivery. You do not need to manually activate it.
Table 3-3 Products and minimum versions supporting PIM-SM

Required
CE5810EI V100R002C00
CE5850EI V100R001C00
CE5850HI V100R003C00
CE5855EI V100R006C00
CE5880EI V200R005C10
CE6810EI V100R003C00
CE6850EI V100R001C00
CE6850-48S6Q-HI V100R005C00
CE6855HI V200R001C00
CE6856HI V200R002C50


Required
CE6857EI V200R005C10
CE6860EI V200R002C50
CE6865EI V200R005C00
CE6870-48T6CQ-EI V200R002C50
CE6875EI V200R003C00
CE6880EI V200R002C50
CE6881/CE6820/CE6863 V200R005C20
CE7850EI V100R003C00
CE7855EI V200R001C00
CE8850-32CQ-EI V200R002C50
CE8850-64CQ-EI V200R005C00
CE8860EI V100R006C00
CE8861EI/CE8868EI V200R005C10
Table 3-4 Products and minimum versions supporting Bidir-PIM

Required
CE5810EI/CE5850EI V100R002C00
CE5850HI V100R003C00
CE5855EI V100R006C00
CE6810EI V100R003C00
CE6850EI V100R002C00
CE6850-48S6Q-HI V100R005C00
CE6855HI V200R001C00
CE6856HI V200R002C50
CE6857EI V200R005C10
CE6860EI V200R002C50


Required
CE6865EI V200R005C00
CE6870-48T6CQ-EI V200R002C50
CE6875EI V200R003C00
CE7850EI V100R003C00
CE7855EI V200R001C00
CE8850-32CQ-EI V200R002C50
CE8850-64CQ-EI V200R005C00
CE8860EI V100R006C00
CE8861EI/CE8868EI V200R005C10
Table 3-5 Products and minimum versions supporting PIM-DM

Product Minimum Version Required
CE5810EI/CE5850EI/CE5855EI/CE5850HI V100R006C00
CE5880EI V200R005C10
CE6810EI/CE6850EI/CE6850HI/ V100R006C00
CE6850U-HI/CE6851HI
CE6855HI V200R001C00
CE6856HI V200R002C50
CE6857EI V200R005C10
CE6860EI V200R002C50
CE6865EI V200R005C00
CE6870-48T6CQ-EI V200R002C50
CE6875EI V200R003C00
CE6880EI V200R002C50
CE6881/CE6820/CE6863 V200R005C20
CE7850EI V100R006C00
CE7855EI V200R001C00

Product Minimum Version Required
CE8850-32CQ-EI V200R002C50
CE8850-64CQ-EI V200R005C00
CE8860EI V100R006C00
CE8861EI/CE8868EI V200R005C10
Feature Limitations
When configuring PIM-SM, pay attention to the following points:
l In V200R001C00 and earlier versions, PIM-SM can only be configured in the public
network instance. Starting with V200R001C00, PIM-SM can be configured in the public
network instance and VPN instances.
l You can configure a static rendezvous point (RP) and dynamic RP simultaneously on a
PIM-SM network. The static RP has a lower priority than the dynamic RP and works as
a backup RP. When you configure static RP and dynamic RP simultaneously, ensure that
all devices have consistent RP information. Otherwise, faults may occur on the network.
l When configuring PIM-SM in the SSM model, configure the same SSM group address
range on all the PIM devices.
l PIM-SM cannot be configured together with PIM-DM in the same instance on a switch.
l A multicast network does not allow routes that are destined for the same group address
and generated by different PIM protocols. Therefore, if you change the PIM mode from
PIM-SM to Bidir-PIM or from Bidir-PIM to PIM-SM, the system displays a message
stating that some multicast routes will be deleted due to change of the PIM mode. Before
you continue, determine whether multicast services will be affected if these multicast
routes are deleted.
l To switch between the PIM-DM and PIM-SM modes, run the undo multicast routing-
enable command in the system view to disable multicast routing, run the multicast
routing-enable command to enable multicast routing again, and then enable PIM-DM or
PIM-SM.
l The number of ingress VLAN interfaces of all multicast groups cannot be more than
multicast entry number.
l The IP address of a multicast source must be located on a different network segment
from the secondary IP address of the interface that connects to the multicast source.
Otherwise, multicast traffic may fail to be forwarded.
When configuring Bidir-PIM, pay attention to the following points:
l Bidir-PIM can only be configured in the public network instance, and cannot be
configured in a VPN instance.
l A super virtual fabric (SVF) system and an M-LAG do not support Bidir-PIM.
l On the CE6875EI and CE6870EI, Layer 3 sub-interfaces and physical interfaces that are
switched to Layer 3 mode using the undo portswitch command support Bidir-PIM. On
switches of the other models, Layer 3 sub-interfaces and physical interfaces that are

switched to Layer 3 mode using the undo portswitch command do not support Bidir-
PIM.
l Bidir-PIM cannot be configured together with PIM-DM in the same instance on a switch.
l A multicast network does not allow routes that are destined for the same group address
and generated by different PIM protocols. Therefore, if you change the PIM mode from
PIM-SM to Bidir-PIM or from Bidir-PIM to PIM-SM, the system displays a message
stating that some multicast routes will be deleted due to change of the PIM mode. Before
you continue, determine whether multicast services will be affected if these multicast
routes are deleted.
When configuring PIM-DM, pay attention to the following points:
l PIM-DM can only be configured in the public network instance, and cannot be
configured in a VPN instance.
l To switch between the PIM-DM and PIM-SM modes, run the undo multicast routing-
enable command in the system view to disable multicast routing, run the multicast
routing-enable command to enable multicast routing again, and then enable PIM-DM or
PIM-SM.
l PIM-DM conflicts with the following features and cannot be configured together with
them:
– VPN instance: PIM-DM cannot be enabled on an interface if a VPN instance has
been bound to the interface.
– PIM-SM and Bidir-PIM: PIM-DM cannot be configured together with PIM-SM or
Bidir-PIM in the same instance on a switch.
– IGMP snooping: After PIM-DM is enabled on a VLANIF interface, IGMP
snooping cannot be enabled in the corresponding VLAN. Similarly, after IGMP
snooping is enabled in a VLAN, PIM-DM cannot be enabled on the corresponding
VLANIF interface.
– Multicast source filtering
– PIM neighbor filtering
– PIM silent
– PIM IPSec
– DR switchover delay
– SSM group policy
– Multicast load splitting
When configuring IPv4 multicast together with other services, pay attention to the
following points:
Table 3-6 Precautions to be observed when you configure IPv4 multicast together with other
services
Item Precautions
IPv4 Layer 3 In versions earlier than V100R006C00, M-LAG does not support IPv4
multicast is Layer 3 multicast.

Item Precautions
deployed with In V100R006C00 and later versions, an M-LAG set up with standalone
M-LAG switches, SVF systems, or stack systems supports IPv4 Layer 3
multicast. Pay attention to the following points:
must be enabled on all the VLANIF interfaces that need to run Layer
3 multicast services, and IGMP snooping must be enabled in the
corresponding VLANs.
between the M-LAG master and backup devices, and PIM must be
enabled on the interfaces at both ends of the Layer 3 link.
l If the Layer 3 link is established between VLANIF interfaces of the
M-LAG master and backup devices, STP must be disabled on the
VLANIF interfaces, and the corresponding VLAN of the VLANIF
interfaces cannot be allowed on the peer-link.
l If the peer-link is selected as the optimal link to the RP or multicast
source by the unicast routing protocol, multicast traffic with the peer-
link interface as the outbound interface may fail to be forwarded. To
prevent this problem, ensure that the Layer 3 link between the M-
LAG master and backup devices has a route cost smaller than or
equal to the route cost of the peer-link, so that the Layer 3 link is
selected as the optimal route by the unicast routing protocol.

l In V200R003C00 and later versions, both the M-LAG master and
backup member interfaces forward multicast traffic to the Receiver,
implementing load sharing. The M-LAG master and backup devices
share load according to the following rule: If the last decimal number
of the multicast group address is an odd number, such as the address
225.1.1.1, the M-LAG master member interface forwards the
multicast traffic. If the last decimal number of the multicast group
address is an even number, such as the address 225.1.1.2, the M-
LAG backup member interface forwards the multicast traffic.
l If the M-LAG master and backup devices run different versions, the
multicast traffic forwarding rule is subject to the device running the
earlier version.
When configuring the (S, G) or (*, G) entry timeout period, pay attention to the
following points:
When configuring multicast functions, you may need to adjust the (S, G) or (*, G) entry
timeout period based on the number of multicast entries used on your network. To set the (S,

G) or (*, G) entry timeout period, run the source-lifetime interval command in the PIM view
of the public network instance or a VPN instance. The following table lists the recommended
timeout period values in different conditions.
1000 to 2000 1000 seconds
2000 to 8000 2000 seconds
3.6 Default Settings for IPv4 PIM

Table 3-7 lists the default settings for IPv4 PIM.
Table 3-7 Default settings for IPv4 PIM

Multicast routing Disabled
PIM-DM Disabled
State refresh Enabled after PIM-DM is enabled
PIM-SM Disabled
Static RP address Unspecified
C-RP interface Unspecified
C-BSR interface Unspecified
Listening of Auto-RP Disabled

messages
DR priority 1
SPT switchover conditions First multicast packet received by the RP or the DR at the
member side
Range of SSM group 232.0.0.0/8

addresses
Bidir-PIM Disabled
PIM BFD Disabled
PIM silent Disabled

3.7 Configuring IPv4 PIM-DM
Context
The PIM-DM protocol implements multicast routing and data forwarding in a domain. The
PIM-DM protocol is a multicast routing protocol in dense mode and applies to small-scale
networks with densely-distributed group members.
3.7.1 Configuring Basic IPv4 PIM-DM Functions
Before configuring basic PIM-DM functions, configure a unicast routing protocol to ensure
normal unicast routing on the network.
Context
After PIM-DM is enabled on all the devices on a PIM-DM network, they use the Any-Source
Multicast (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.
PIM-DM cannot be configured together with PIM-SM in the same instance on a switch.
It is recommended that you enable PIM-DM on all interfaces on a PIM-DM network, so that
the interfaces can establish neighbor relationships with all connected PIM devices.
Procedure
Step 2 Run multicast routing-enable
The multicast routing function is enabled.
By default, the multicast routing function is disabled.

1. Run quit
interface.
Step 6 Run pim dm
PIM-DM is enabled on the interface.
By default, PIM-DM is disabled on an interface.
Step 7 Run commit
----End

After PIM-DM is enabled on all the devices in a PIM domain, use the following commands to
check information about PIM interfaces, PIM neighbors, and PIM routing entries.
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:
– Run the 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 dm | flags flag-value | fsm ] * [ outgoing-interface-number
[ number ] ] command to check detailed information about the PIM routing table.
– Run the display pim routing-table brief [ group-address [ mask { group-mask-
length | group-mask } ] | source-address [ mask { source-mask-length | source-
mask } ] | incoming-interface { interface-type interface-number | register } ] *
command to check brief information about the PIM routing table.

3.7.2 Setting the Lifetime of a Multicast Source in IPv4 PIM-DM
Before setting the lifetime of a multicast source, complete the following task:
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 lifetime of the source. 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 of the source, it considers the
corresponding (S, G) entry invalid and deletes this entry.
Default Settings
Table 3-8 lists default settings of control parameters for a multicast source.
Table 3-8 Default settings of multicast source control parameters

Keepalive period of a 210s

multicast source
Procedure
Step 2 Run pim
The PIM view is displayed.
Step 3 Run source-lifetime interval
The lifetime of a multicast source is configured.
Step 4 Run commit
----End

Run the following commands to check the PIM routing table.
l Run the display pim routing-table [ group-address [ mask { group-mask-length |
incoming-interface { interface-type interface-number | register } | outgoing-interface

{ include | exclude | match } { interface-type interface-number | register | none } |

mode dm | flags flag-value | fsm ] * [ outgoing-interface-number [ number ] ]
command to check detailed information about the PIM routing table.
l Run the display pim routing-table brief [ group-address [ mask { group-mask-length |
incoming-interface { interface-type interface-number | register } ] * command to check
brief information about the PIM routing table.
3.7.3 Adjusting Control Parameters for Establishing Neighbor

Relationships in IPv4 PIM-DM
Context
By adjusting parameters that control Hello message exchange between neighbors, you can
prevent unauthorized devices from establishing PIM neighbor relationships with the local
device. This guarantees security of a PIM-DM network.
You can adjust time parameters for Hello messages, and configure an interface to reject Hello
messages without a Generation ID in any sequence as required.
3.7.3.1 Adjusting Time 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.
The interval for sending Hello messages and the holdtime of Hello messages can be configured 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.
Default Settings
Table 3-9 lists default settings of time parameters for Hello messages.

Table 3-9 Default settings of time parameters for Hello messages

Interval for sending Hello 30s

messages
Holdtime of Hello 105s

messages
Procedure
l Global configuration
a. Run system-view
b. Run pim
c. Run timer hello interval
The interval for sending Hello messages is configured.
d. Run hello-option holdtime interval
The holdtime of Hello messages is configured.
e. Run commit
l Configuration on an interface
a. Run system-view


i. Run quit
sub-interface.
e. Run pim timer hello interval
f. Run pim hello-option holdtime interval
g. Run commit
----End
3.7.3.2 Configuring an Interface to Reject Hello Messages Without a Generation

ID
Context
After PIM is enabled on an interface, the local switch generates a random number as the
Generation ID of Hello messages. If the status of the switch changes (for example, it restarts),
the switch generates a new Generation ID. When a remote device receives a Hello message
with the new Generation ID, it considers that the PIM neighbor status has changed and sends
Hello messages to set up a PIM neighbor relationship with the switch again. That is, a switch
can detect changes of a PIM neighbor's status through the Generation ID in the Hello message
received from the neighbor. Sometimes, a switch may receive Hello messages without a
Generation ID. To enable the switch to maintain normal PIM neighbor relationships with
other devices, you can configure the switch to reject Hello messages without a Generation ID.
Procedure


1. Run quit
interface.
Step 5 Run pim require-genid
The switch is configured to receive only Hello messages that contain Generation IDs.
By default, a PIM interface receives the Hello messages without the Generation ID.
Step 6 Run commit
----End
3.7.3.3 Verifying the Configuration of Control Parameters for Establishing

Neighbor Relationships in IPv4 PIM-DM
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


----End
3.7.4 Adjusting Control Parameters for Prune Messages in IPv4

PIM-DM
Context
A multicast device sends Prune messages upstream for requiring to stop forwarding multicast
data. You can configure control parameters for Prune messages as required. If there is no
special requirement, the default values are recommended.
You can configure time parameters for Join/Prune messages, Join/Prune message packaging,
and Prune delay in any sequence as required.
3.7.4.1 Adjusting Time Parameters for Join/Prune Messages
Context
A PIM device sends Prune messages to its upstream neighbor to request the neighbor to stop
sending multicast data to it. Prune messages are encapsulated in a Join/Prune message, which
is defined by the PIM protocol to control multicast forwarding. When the upstream neighbor
receives a Join/Prune message, it starts a timer and sets the timer value to the holdtime of the
Join/Prune message. If the upstream neighbor does not receive any Join/Prune message when
the timer expires, the upstream neighbor starts to forward multicast data to the downstream
interface again.
The holdtime of Join/Prune messages can be configured in the PIM view or interface view. If the
holdtime is configured both in the PIM view and interface view, the configuration in the interface view
takes effect.
Default Settings
Table 3-10 lists the default settings of time parameters for Join/Prune messages.
Table 3-10 Default settings of time parameters for Join/Prune messages

Holdtime of Join/Prune messages 210s

Procedure
a. Run system-view
b. Run pim
c. Run holdtime join-prune interval
The holdtime of Join/Prune messages is configured.
d. Run commit
a. Run system-view
i. Run quit
sub-interface.

e. Run pim holdtime join-prune interval

f. Run commit
----End
3.7.4.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 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 real-time Join/Prune
message packaging function.
Procedure
Step 2 Run pim
Step 3 Run join-prune triggered-message-cache disable
The real-time Join/Prune message packaging function is disabled.
By default, the real-time Join/Prune message package function is enabled.
Step 4 Run commit
----End
3.7.4.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.

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.
Default Settings
Table 3-11 lists the default settings of control parameters for prune delay.
Table 3-11 Default settings of control parameters for prune delay

LAN-delay 500 ms
Override-interval 2500 ms
Procedure
a. Run system-view
b. Run pim
c. Run hello-option lan-delay interval
The delay for transmitting Prune messages is configured.
d. Run hello-option override-interval interval
The interval for overriding the prune action is configured.
e. Run commit
a. Run system-view

i. Run quit
sub-interface.
e. Run pim hello-option lan-delay interval
The delay for transmitting Prune messages is configured.
f. Run pim hello-option override-interval interval
g. Run commit
----End
3.7.4.4 Verifying the Configuration of Control Parameters for Prune Messages in

IPv4 PIM-DM
Prerequisites
After control parameters for 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 display pim control-message counters [ message-type { assert | hello | join-
prune | graft | graft-ack | state-refresh } | interface interface-type interface-number ] *
command to check the number of sent or received PIM control messages.
l Run the following commands to check the PIM routing table.


----End
3.7.5 Adjusting Graft Control Parameters in IPv4 PIM-DM
Context
To quickly resume multicast forwarding to a pruned network segment, the switch sends a
Graft message to its upstream neighbor and starts a timer on the upstream interface. If the
switch does not receive multicast data when the timer expires, it retransmits the Graft message
to the upstream neighbor. You can control multicast packet forwarding by adjusting the graft
control parameters to meet requirements in various scenarios.
Default Settings
The default retransmission interval of Graft messages is 3s.
Procedure

1. Run quit
interface.
Step 5 Run pim timer graft-retry interval
The retransmission interval of Graft messages is configured.
Step 6 Run commit
----End

After adjusting the retransmission interval of Graft messages on an interface, check PIM-DM
graft information and PIM information on the interface to see whether the configuration meets
the service requirements.
l Run the display pim grafts command to check information about PIM-DM Graft
messages that have not been acknowledged by the upstream neighbor.
3.7.6 Adjusting State Refresh Control Parameters in IPv4 PIM-

DM
Context
PIM-DM provides a state refresh mechanism to prevent pruned interfaces from resuming
multicast forwarding due to prune state timeout. The first-hop device directly connected to a

multicast source sends State-Refresh messages at intervals to reset the prune timers on pruned
interfaces and maintain the SPT.
You can disable forwarding of State-Refresh messages, set time parameters of State-Refresh
messages, and set the TTL value of State-Refresh messages at any sequence as required.
3.7.6.1 Disabling Forwarding of State-Refresh Messages
Context
Pruned interfaces can resume multicast forwarding when the prune timer expires, even though
no downstream devices need to receive multicast data. To prevent this problem, the PIM
device directly connected to a multicast source sends State-Refresh messages at intervals to
update state of (S, G) entries. A State-Refresh message is propagated to downstream devices
hop by hop to reset prune timers on all the PIM devices. In this way, interfaces that do not
need to forward multicast data retain in prune state.
By default, all PIM devices can forward State-Refresh messages. If you want multicast data to
be flooded on the entire network in every flood-prune process and do not want to prevent
pruned interface from resume multicast forwarding, disable forwarding of State-Refresh
messages on device interfaces.
Disabling forwarding of State-Refresh messages is not recommended because State-Refresh messages

can conserve network resources.
Procedure

1. Run quit



interface.
Step 5 Run undo pim state-refresh-capable
Forwarding of State-Refresh messages is disabled on the interface.
By default, forwarding of State-Refresh messages is enabled on the interface.
To enable the interface to forward State-Refresh messages again, run the pim state-refresh-
capable command on the interface.
Step 6 Run commit
----End
3.7.6.2 Adjusting Time Parameters for State-Refresh Messages
Context
The PIM device directly connected to a multicast source sends State-Refresh messages at
intervals to downstream devices. State-Refresh messages are flooded on the entire network, so
a device may receive duplicate State-Refresh messages within a short time. To prevent this
problem, a device starts a timer when receiving a State-Refresh message for an (S, G) entry.
The timer value is the suppression time of the State-Refresh message. If the device receives
the same State-Refresh messages before the timer expires, it drops the received State-Refresh
messages.
Default Settings
Table 3-12 lists the default settings of time parameters for State-Refresh messages.

Table 3-12 Default settings of time parameters for State-Refresh messages

Interval for sending State- 60s

Refresh messages
Suppression time of 30s

duplicate State-Refresh
messages
Procedure
l Set the interval for sending State-Refresh messages on the device directly connected to a
multicast source.
a. Run system-view

b. Run pim

c. Run state-refresh-interval interval
The interval for sending State-Refresh messages is set.

d. Run commit

l Set the suppression time of duplicate State-Refresh messages on all the PIM devices.
a. Run system-view

b. Run pim

c. Run state-refresh-rate-limit interval
The suppression time of duplicate State-Refresh messages is set.

d. Run commit
----End
3.7.6.3 Setting the TTL Value of State-Refresh Messages
Context
When a device receives a State-Refresh message, it reduces the time-to-live (TTL) value of
the message by 1 and forwards the message to downstream devices. The State-Refresh
message is transmitted on the network until its TTL value reduces to 0. On a small-scale
network, State-Refresh messages with a large TTL value are transmitted circularly. To control

the transmission range of State-Refresh messages, set a proper TTL value for State-Refresh
messages according to the network scale.
Because State-Refresh messages are originated from the first-hop device connected to a multicast
source, the TTL value of State-Refresh messages must be configured on the first-hop device.
Default Settings
The default TTL value of State-Refresh messages is 255.
Procedure
Step 2 Run pim
Step 3 Run state-refresh-ttl ttl-value
The TTL value of State-Refresh messages is set.
Step 4 Run commit
----End
3.7.6.4 Verifying the Configuration of State Refresh Control Parameters in IPv4

PIM-DM
Prerequisites
After adjusting state refresh control parameters, you can check information about the PIM
interface, statistics about PIM control messages, and PIM routing table.
Procedure
command to check the number of PIM control messages sent and received from an
interface.


----End
3.7.7 Adjusting Assert Control Parameters in IPv4 PIM-DM
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. When a
device receives multicast data through a downstream interface, it 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.
PIM devices that lose the assert election disable their downstream interfaces from forwarding
multicast data to this network segment. The assert loser state lasts for a period of time, which
is called the holdtime of Assert messages. After the holdtime expires, the assert losers restore
pruned interfaces to the forwarding state to trigger a new Assert election.
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
Default Settings
The default holdtime of Assert messages is 180s.
Procedure
a. Run system-view
b. Run pim
c. Run holdtime assert interval
The holdtime of Assert messages is configured.
d. Run commit
a. Run system-view


i. Run quit
sub-interface.
e. Run pim holdtime assert interval
The period for holding the Assert state is configured.
f. Run commit
----End

After assert control parameters are configured, you can check information about the PIM
interface, PIM neighbors, and PIM routing table using the following commands:


3.7.8 Configuring a Limit on the Number of IPv4 PIM-DM Entries
Context
IPv4 PIM-DM allows you to limit the number of (S, G) and (*, G) entries separately. After a
specified limit is reached, new entries of the corresponding type cannot be created.
Limit the number of PIM entries to prevent a device from generating excessive multicast
routing entries when attackers send numerous multicast data or IGMP/PIM protocol
messages. Therefore, this function helps prevent high memory and CPU usage and improve
multicast service security.
Procedure
Step 2 Run multicast global limit pim dm { star-group-number | source-group-number } limit-

count [ threshold-alarm upper-limit upper-limit-value lower-limit lower-limit-value ]
A limit on the number of PIM entries and alarm trigger and clear thresholds are set. After the
command is run:
l After the specified limit is reached, new entries are not created, and the
PIM_1.3.6.1.4.1.2011.5.25.149.4.0.23 routeExceed alarm is generated.
After the specified limit is reached, new (*, G) and (S, G) entries can be manually added.
l If upper-limit upper-limit-value is set, the PIM_1.3.6.1.4.1.2011.5.25.149.4.0.21
routeThresholdExceed alarm is generated when the percentage ratio of created PIM
entries to the specified limit reaches upper-limit-value.
By default, no limit is set on the number of global IPv4 PIM entries.
Step 3 Run commit
----End


After a limit on the number of global IPv4 PIM entries is configured, you can check PIM
entry restriction and statistics.
Run the display multicast global pim dm statistics command to check PIM entry restriction
and statistics.
3.8 Configuring IPv4 PIM-SM
Context
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.8.1 Configuring IPv4 PIM-SM in the ASM Model
Context
A PIM-SM network uses the Any-Source Multicast (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 optional configuration tasks as required.
3.8.1.1 Enabling PIM-SM
Context
It is recommended that you enable PIM-SM on all interfaces in a PIM-SM domain to ensure
that the interfaces can establish neighbor relationships with all connected PIM devices.
Procedure
l Enable PIM-SM for a public network instance.
a. Run system-view


i. Run quit
sub-interface.
f. Run pim sm
PIM-SM is enabled.
g. Run commit
l Enable PIM-SM for a VPN instance.
A VPN instance must exist before you enable PIM-SM in the VPN instance.
a. Run system-view

c. Run ipv4-family
f. Run quit
g. Run quit
i. Run quit
sub-interface.

The interface is associated with a specified VPN instance.

l. Run pim sm
PIM-SM is enabled.
m. Run commit
----End
3.8.1.2 Configuring an RP
Context
A rendezvous point (RP) can be configured manually or elected through the bootstrap router
(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.
NOTICE
You can configure a static RP and multiple candidate rendezvous points (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 Settings
Table 3-13 lists the default settings of the C-BSR and C-RP.
Table 3-13 Default settings of the C-BSR and C-RP

C-BSR priority 0
C-BSR hash mask length 30
BSR message Disabled

fragmentation
Multicast group policy of No multicast group policy configured (receiving multicast

a static RP data with any group address)

a C-RP data with any group address)

C-RP priority 0
Interval for sending C-RP 60s

Announcement messages
Hold time of C-RP 150s

Procedure
l Configure a static RP.
a. Run system-view

b. Run pim [ vpn-instance vpn-instance-name ]

c. 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.
All devices in the PIM-SM domain must be configured with the same static RP address.
d. Run commit

l Configure a dynamic RP.
a. Configure a C-BSR.
i. Run system-view
ii. Run pim [ vpn-instance vpn-instance-name ]
iii. Run c-bsr interface-type interface-number [ hash-length [ priority ] ]
A C-BSR is configured.
It is recommended that you configure the C-BSR on the device that aggregates
multicast data.
To avoid frequent protocol changes caused by interface flapping, using loopback

interfaces is recommended.
iv. (Optional) Run bsm semantic fragmentation
The BSR message fragmentation function is enabled.

BSR message fragmentation solves the problem in IP fragmentation, where 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 RP information.
v. Run commit
b. Configure a C-RP.
i. Run system-view
ii. Run pim [ vpn-instance vpn-instance-name ]
iii. 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.
To avoid frequent protocol changes caused by interface flapping, using loopback

interfaces is recommended.
iv. Run commit
c. (Optional) Configure a BSR boundary.
i. Run system-view
ii. Run interface interface-type interface-number
iii. On an Ethernet interface, run undo portswitch
Alternatively, if configuration information supported by both Layer 2 and
Layer 3 interfaces exists (for example, mode lacp and lacp system-id
configurations), no configuration that is not supported after the working mode
of the interface is switched can exist. If unsupported configurations exist on
the interface, delete the configurations first and then run the undo portswitch
command.
If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo
portswitch batch interface-type { interface-number1 [ to interface-number2 ] }
&<1-10> command in the system view to switch these interfaces to Layer 3 mode in
batches.

iv. For a Layer 3 sub-interface, run the following commands to configure

termination of single-tagged packets on it.
1) Run quit
2) Run interface interface-type interface-number.subinterface-number
number on an Ethernet interface that has been switched to the Layer 3
mode.
3) Run dot1q termination vid vid
By default, the termination of Dot1q packets is not configured on a Layer
3 sub-interface.
v. Run pim bsr-boundary [ incoming ]
A BSR service boundary is configured.
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.
vi. Run commit
l Enable listening of Auto-RP messages.
a. Run system-view


c. Run auto-rp listening enable
Listening of Auto-RP messages is enabled.

d. Run commit
----End
3.8.1.3 (Optional) Configuring a BSR Administrative Domain
Context
To facilitate PIM domain management, a PIM network is divided into multiple bootstrap
router (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.

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 [ vpn-instance vpn-instance-name ]
3. Run c-bsr admin-scope
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 interface interface-type interface-number
3. On an Ethernet interface, run undo portswitch
configurations (for example, shutdown and description configurations). Alternatively, if
configuration information supported by both Layer 2 and Layer 3 interfaces exists (for
example, mode lacp and lacp system-id configurations), no configuration that is not
supported after the working mode of the interface is switched can exist. If unsupported
configurations exist on the interface, delete the configurations first and then run the undo
portswitch command.
interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system
view to switch these interfaces to Layer 3 mode in batches.
4. For a Layer 3 sub-interface, run the following commands to configure termination of
single-tagged packets on it.
a. Run quit
b. Run interface interface-type interface-number.subinterface-number
The subinterface-number parameter must specify a Layer 3 sub-interface number
on an Ethernet interface that has been switched to the Layer 3 mode.

c. Run dot1q termination vid vid

interface.
5. Run multicast boundary group-address { mask | mask-length }
The boundary of the BSR administrative domain is configured.
Multicast packets that belong to the BSR administrative domain cannot traverse the
boundary.
6. Run commit
Step 3 Configure a group address range for the C-BSR in each BSR administrative domain.
1. Run system-view


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


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.8.1.4 (Optional) Configuring the SPT Switchover Condition
Context
A high volume of multicast data traffic increases the load of a rendezvous point (RP) and may
result in a fault. The designated router (DR) at the group member side triggers SPT
switchover to reduce the burden of the RP.

By default, a DR at the group member side immediately triggers shortest path tree (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.
Default Settings
Table 3-14 lists the default settings of SPT switchover conditions.
Table 3-14 Default settings of SPT switchover conditions
Group policy that specifies No group policy configured (The SPT switchover conditions
the groups to which the apply to all multicast groups.)
SPT switchover conditions
apply
Interval for checking the 15s

forwarding rate of
multicast data
Procedure
Step 2 Run pim [ vpn-instance vpn-instance-name ]
Step 3 Run 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.8.1.5 (Optional) Adjusting Control Parameters for Source Registration

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 registration 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.
l Control the source DR from sending Register messages when the DR receives multicast
traffic. When the source DR receives multicast data, it sends Register messages to the
RP, and add registered egress interface. If too many redundant Register messages are
sent to RP, the performance is affected. After the Register messages sending function is
disabled on the source DR, the DR sends Probe messages instead of Register messages,
so that the performance is not affected.
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.
Default Settings
Table 3-15 lists default settings of control parameters for source registration.
Table 3-15 Default settings of control parameters for source registration
Filter policy for Register No filter policy configured (receiving Register messages with
messages any group address)
Way to calculate the Based on the entire message

checksum
Register message 60s

suppression time
Interval for sending null 5s

Register messages

Control the source DR When the DR receives multicast traffic, it sends Register
from sending Register messages to the RP.
messages
Procedure
l Configure control parameters for source registration on the source DR.
a. Run system-view
c. Run register-suppression-timeout interval
Register message suppression time is configured.
d. Run probe-interval interval
The interval for sending null Register messages is configured.
The value of probe-interval must be smaller than half of register-suppression-timeout.

e. Run register-packet-checksum
The checksum is calculated based on all the contents of a Register message.
f. 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.
g. Run register-with-probe
The source DR is configured to send only Probe messages when it receives
multicast traffic from the multicast source. No Register message is sent, so that the
performance is not affected.
h. Run commit
l Configure control parameters for source registration on the RP.
a. Run system-view
c. Run register-policy { advanced-acl-number | acl-name acl-name }
A policy for filtering Register messages is configured.

d. Run commit
----End
3.8.1.6 (Optional) Adjusting C-RP Control Parameters
Context
When a candidate rendezvous point (C-RP) is configured on an interface, the C-RP
periodically sends Advertisement messages to a bootstrap router (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.
a. Run system-view
c. Run c-rp priority priority
The C-RP priority is configured.
d. Run c-rp advertisement-interval interval
The interval for sending Advertisement messages is configured.
e. Run c-rp holdtime interval
The time period to hold the Advertisement messages received from the C-RP is
configured.
f. Run commit
l Configure the valid C-RP address range on the BSR.
a. Run system-view


c. Run c-rp 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.
d. Run commit
----End
3.8.1.7 (Optional) Adjusting C-BSR Control Parameters
Context
Candidate bootstrap routers (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.
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.
Default Settings
Table 3-16 lists the default settings of the C-BSR.
Table 3-16 Default settings of the C-BSR
Interval for sending 60s

Bootstrap messages
Holdtime of Bootstrap 130s

messages

Procedure
l Configure parameters contained in a Bootstrap message for a C-BSR.
a. Run system-view
c. Run c-bsr priority priority
The priority of the C-BSR is configured.
d. Run c-bsr hash-length priority
The hash mask length of the C-BSR is configured.
e. Run c-bsr interval interval
The interval for the BSR to send Bootstrap messages is configured.
f. Run c-bsr holdtime interval
The holdtime of the Bootstrap message received from the BSR is configured.
g. Run commit
l Configure a valid BSR address range on a PIM device.
a. Run system-view
c. Run bsr-policy { basic-acl-number | acl-name acl-name }
The range of valid BSR addresses is configured.
d. Run commit
----End
3.8.1.8 Verifying the Configuration of IPv4 PIM-SM in the ASM Model
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 [ vpn-instance vpn-instance-name | all-instance ] bsr-info
command to check the BSR configuration.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] rp-info [ group-
address ] command to check the RP configuration.

l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] interface

[ interface-type interface-number | up | down ] [ verbose ] command to check PIM
information on an interface.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] neighbor
[ neighbor-address | interface interface-type interface-number | verbose ] * command to
check information about PIM neighbors.
– display pim routing-table [ group-address [ mask { group-mask-length | group-
mask } ] | source-address [ mask { source-mask-length | source-mask } ] |
| none } | mode { sm | ssm } | flags flag-value | fsm ] * [ outgoing-interface-
number [ number ] ]
– display pim { vpn-instance vpn-instance-name | all-instance } 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 { ssm | sm } |
flags flag-value | fsm ] * [ outgoing-interface-number [ number ] ]
– display pim [ vpn-instance vpn-instance-name | all-instance ] routing-table brief
type interface-number | register } ] *
----End
3.8.2 Configuring IPv4 PIM-SM in the SSM Model
Context
A PIM-SM network uses the Source-Specific Multicast (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.8.2.1 Enabling PIM-SM
Context
It is recommended that you enable PIM-SM on all interfaces in a PIM-SM domain to ensure
that the interfaces can establish neighbor relationships with all connected PIM devices.

Procedure
l Enable PIM-SM for a public network instance.
a. Run system-view
i. Run quit
sub-interface.
f. Run pim sm
PIM-SM is enabled.
g. Run commit
l Enable PIM-SM for a VPN instance.
A VPN instance must exist before you enable PIM-SM in the VPN instance.

a. Run system-view


c. Run ipv4-family

f. Run quit

g. Run quit


i. Run quit


sub-interface.
The interface is associated with a specified VPN instance.
l. Run pim sm
PIM-SM is enabled.
m. Run commit
----End
3.8.2.2 (Optional) Configuring an SSM Group Policy
Context
By default, the Source-Specific Multicast (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 3 Run ssm-policy { basic-acl-number | acl-name acl-name }
The SSM group address range is configured.
Ensure that the SSM group address range of all devices in the network are the same.
Step 4 Run commit

----End
3.8.2.3 Verifying the Configuration of IPv4 PIM-SM in the SSM Model

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 [ number ] ]
----End
3.8.3 Adjusting Control Parameters for a Multicast Source in IPv4

PIM-SM
Before setting the parameters for controlling a multicast source, complete the following tasks:
l Configure a unicast routing protocol to ensure normal unicast routing on the network.
l 3.8.1.1 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.
Default Settings
Table 3-17 lists default settings of multicast source control parameters.


multicast source
Source address filtering No policy configured (Multicast data from all sources is
policy accepted.)
Procedure
The multicast source lifetime is configured.
Configure timeout period of (S, G) or (*, 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 timeout period will make the multicast forwarding table incomplete. However, if the
timeout period is too long, invalid entries will be retained for a long time, wasting system
resources. The following table lists the recommended timeout periods for different quantities
of multicast forwarding entries. In this table, the number of entries refers the total number of
multicast entries in public network instances and VPN instances. It is recommended that you
set the same timeout period in all public network instances and VPN instances based on the
total number of multicast entries in the system.
1000 to 2000 1000 seconds
2000 to 8000 2000 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.
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.

l 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 ] ]
l display pim { vpn-instance vpn-instance-name | all-instance } 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 { ssm | sm } | flags flag-value | fsm ] * [ outgoing-
interface-number [ number ] ]
l display pim [ vpn-instance vpn-instance-name | all-instance ] routing-table brief
[ group-address [ mask { group-mask-length | group-mask } ] | source-address [ mask
{ source-mask-length | source-mask } ] | incoming-interface { interface-type interface-
number | register } ] *

Relationships in IPv4 PIM-SM
Before configuring control parameters for establishing neighbor relationships, complete the
following tasks:

l Enable PIM-SM.
You can configure the Hello message control parameters and neighbor filtering function in
any sequence as required.
3.8.4.1 Adjusting Control Parameters for Hello Messages
Context
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
Default Settings
Table 3-18 lists default settings of control parameters for Hello messages.
Table 3-18 Default settings of control parameters for Hello messages


messages

messages
Procedure
a. Run system-view


e. Run commit
a. Run system-view
i. Run quit
sub-interface.
g. Run commit
----End

3.8.4.2 Configuring PIM Neighbor Filtering
Context
The switch supports different neighbor filtering policies to ensure secure and effective
multicast transmission in a Protocol Independent Multicast Sparse Mode (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
1. Run quit


interface.
Step 5 Run pim neighbor-policy { basic-acl-number | acl-name acl-name }
The range of valid neighbor addresses is configured.
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.
The device is configured to receive only Hello messages that contain Generation IDs.
Step 7 Run commit
----End

Neighbor Relationships in IPv4 PIM-SM
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
----End
3.8.5 Adjusting Control Parameters for DR Election in IPv4 PIM-

SM
Before configuring control parameters for DR election, complete the following tasks:
l Enable PIM-SM.

You can configure the priority for DR election and DR switchover delay in any sequence as
required.
3.8.5.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
designated router (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.
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.
Default Settings
The default DR priority is 1.
Procedure
a. Run system-view
c. Run hello-option dr-priority priority
The priority for DR election is configured.
d. Run commit
a. Run system-view

i. Run quit
sub-interface.
e. Run pim hello-option dr-priority priority
The priority for DR election is configured.

f. Run commit
----End
3.8.5.2 Configuring the DR Switchover Delay
Context
When an interface on a shared network segment changes from a designated router (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 function and set a delay time. When the DR changes, the
original multicast forwarding entries are retained within the delay time.
Procedure

1. Run quit



interface.
Step 5 Run pim timer dr-switch-delay interval
The DR switchover delay function is enabled and a delay time is configured.
By default, when the interface changes from a DR to a non-DR, the interface stops forwarding
data immediately.
Step 6 Run commit
----End
3.8.5.3 Verifying the Configuration of Control Parameters for DR Election in IPv4

PIM-SM

Prerequisites
After the control parameters for electing a DR are adjusted, you can check information about
the PIM interface and the PIM neighbor.
Procedure
----End
3.8.6 Adjusting Control Parameters for Join/Prune Messages in

IPv4 PIM-SM
Before configuring control parameters for Join/Prune messages, complete the following tasks:
l Enable PIM-SM.
Context
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
control parameters for Join/Prune messages as required. If there is no special requirement, the
default values are recommended.
You can configure time parameters for Join/Prune messages, disable Join/Prune packaging,
Prune delay, and Join information filtering in any sequence as required.
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 message
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.
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.
Default Settings

Interval for sending Join/Prune messages 60s
Procedure
a. Run system-view
c. Run timer join-prune interval
The interval for sending Join/Prune messages is configured.
d. Run holdtime join-prune interval
e. Run commit
a. Run system-view


i. Run quit
sub-interface.
e. Run pim timer join-prune interval
f. Run pim holdtime join-prune interval
g. Run commit
----End
Context

message package. To prevent packets from being discarded, disable the Join/Prune message
packaging function.
Procedure
Step 4 Run commit
----End
Context
the time it performs the prune action is the sum of the LAN-delay and override-interval.
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
Default Settings
LAN-delay 500 ms

Procedure
a. Run system-view


The delay for transmitting messages in a shared network is configured.


e. Run commit

a. Run system-view


i. Run quit


sub-interface.
g. Run commit
----End
3.8.6.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
1. Run quit




interface.
Step 5 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 6 Run commit
----End
3.8.6.5 Verifying the Configuration of Control Parameters for Join/Prune

Messages in IPv4 PIM-SM
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 [ vpn-instance vpn-instance-name | all-instance ] control-message
counters message-type { probe | register | register-stop | crp }
counters [ message-type { assert | hello | join-prune | bsr } | interface interface-
type interface-number ] *
number [ number ] ]


----End
3.8.7 Adjusting Assert Control Parameters in IPv4 PIM-SM
Before configuring assert control parameters, complete the following tasks:
l Enable 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. When a
device receives multicast data through a downstream interface, it 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.
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.
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
Default Settings
The default holdtime of Assert messages is 180s.
Procedure
a. Run system-view


c. Run holdtime assert interval
The holdtime of Assert messages is configured.
By default, the holdtime of Assert messages is 180 seconds.

d. Run commit

a. Run system-view


i. Run quit
sub-interface.
e. Run pim holdtime assert interval
The period for holding the Assert state is configured.

f. 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 [ number ] ]
3.8.8 Configuring IPv4 PIM-SM Anycast RP
Context
Anycast RP allows several RPs with the same address to be configured in an IPv4 PIM-SM
domain and establish peer relationships, so that a multicast source can register with the closest
RP and receivers can join the closest RP. This releases burdens on a single RP, implements RP
backup, and optimizes multicast forwarding paths. Currently, there are two anycast
implementations: Multicast Source Discovery Protocol (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 IPv4 PIM-SM Anycast RP, complete the following tasks:
l Configure a unicast routing protocol to ensure connectivity at the network layer.

l Configure IPv4 PIM-SM in the ASM Model.
Perform the configuration tasks in the listed sequence.
3.8.8.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 switches
where anycast RP will be deployed.
Procedure
Step 3 Run anycast-rp rp-address
Anycast RP is configured.
The anycast RP address must be the same as that of the RP address on the current network.
Step 4 Run commit
----End
3.8.8.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


The Anycast RP view is displayed.
Step 4 Run local-address local-address
Local addresses are configured for Anycast RP.
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
3.8.8.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
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.
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

3.8.8.4 Verifying the IPv4 PIM-SM Anycast RP Configuration
Context
After IPv4 PIM-SM Anycast RP is configured, you can check the IPv4 PIM-SM Anycast RP
configuration.
Procedure
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] rp-info
command to check the RP.
number [ number ] ]
----End
3.8.9 Configuring IPv4 PIM BFD
Before configuring PIM BFD, complete the following tasks:
l Configuring a unicast routing protocol to ensure normal unicast routing on the network
l Enabling BFD globally using the bfd command
Context
On a PIM network, changes of link status between PIM neighbors will restart some PIM
mechanisms, such as DR election or Assert winner election. For example, when the
designated router (DR) on a shared network segment fails, PIM neighbors on the network
segment trigger DR re-election only when the PIM neighbor relationships time out. Multicast
data transmission is interrupted before a new DR is elected. The multicast service interruption
time is longer than or equal to the neighbor relationship timeout interval, and is usually
several seconds.

PIM Bidirectional Forwarding Detection (BFD) can detect link status changes on a shared
network segment in milliseconds, enabling PIM devices to rapidly respond to failures of PIM
neighbors. If a PIM BFD-capable interface does not receive any BFD packets from the DR
within the detection interval, it considers that the DR has failed. Then BFD rapidly reports the
session status to the route management (RM) module, which then reports the link status
change to the PIM module. After receiving the notification, the PIM module triggers DR re-
election immediately, without waiting for timeout of the neighbor relationship. This
mechanism reduces the multicast service interruption time and improves reliability of
multicast data transmission.
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.
Default Settings
Table 3-21 lists default settings of control parameters for PIM BFD messages.
Table 3-21 Default settings of control parameters for PIM BFD messages
Minimum sending interval 1000 ms
Minimum receiving 1000 ms

interval
Local detection multiplier 3
Procedure

1. Run quit



interface.
Step 5 Run pim bfd enable
PIM BFD is enabled.
Step 6 (Optional) Run pim bfd { min-tx-interval tx-value | min-rx-interval rx-value | detect-
multiplier multiplier-value } *
The parameters of PIM BFD are set.
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.
Step 7 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 [ vpn-instance vpn-instance-name | all-instance ] bfd session statistics

l display pim [ vpn-instance vpn-instance-name | all-instance ] bfd session [ interface
interface-type interface-number | neighbor neighbor-address ] *
3.8.10 Configuring IPv4 PIM Silent
Before configuring PIM Silent, complete the following task:
l Enable PIM-SM.

Context
On the access layer, the PIM protocol must be enabled on the interfaces directly connected to
user hosts, so that the interfaces can establish PIM neighbor relationships to process various
PIM packets. The configuration, however, brings security risks. When a host maliciously
sends many 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.
NOTICE
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

1. Run quit
interface.
Step 5 Run pim silent
The PIM silent function is enabled.
Step 6 Run commit
----End

After PIM silent is configured, you can check information about the PIM interface.
Run the display pim [ vpn-instance vpn-instance-name | all-instance ] interface [ interface-
type interface-number | up | down ] [ verbose ] command to check PIM information on an
interface.
3.8.11 Configuring IPv4 PIM IPSec

PIM IPSec enables a device to encrypt and authenticate PIM messages it sends and receives,
preventing attacks from forged PIM messages.
Before configuring PIM IPSec, complete the following tasks:
Configure PIM IPSec in the following sequence.
3.8.11.1 Configuring Basic IPSec Functions
Context
IPsec can be configured to prevent protocol packets from being intercepted or faked on a
simple network.

A security association (SA) must be established so that IPSec can protect protocol packets.
An SA is a unidirectional logical connection set up for security purpose and specifies the
elements used by two IPSec peers (two parties that use the IPSec protocol to protect protocol
packets between them). The elements of an SA include the following:
l Security protocol
l Authentication or encryption algorithm supported by the security protocol
l Protocol packet encapsulation mode
l Security parameter index (SPI) of the SA
l Authentication key or encryption key of the SA
The first three elements are specified in an IPSec proposal. To configure IPSec functions, first
configure an IPSec proposal on the IPSec peers, and then configure an SA.
Procedure
Step 1 Configure an IPSec proposal.
1. Run system-view

2. Run ipsec proposal proposal-name
An IPSec proposal is created and the IPSec proposal view is displayed.

3. Run transform { ah | esp }
A security protocol is specified for the IPSec proposal.
By default, the security protocol used by an IPSec proposal is the Encapsulation Security
Protocol (ESP).
4. An authentication or encryption algorithm is configured.
– If AH is used, you can only configure the AH-specific authentication algorithm
because AH only authenticates packets.
Run the ah authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 |
sha2-512 } command to specify the authentication algorithm for the AH protocol.
By default, no authentication algorithm is used for AH.
– When ESP is specified, ESP can authenticate, or encrypt and authenticate packets.
Configure the ESP-specific authentication or encryption algorithm.
n Run the esp authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 |
sha2-512 } command to specify the authentication algorithm for the ESP
protocol.
By default, no authentication algorithm is used for ESP.
n Run the esp encryption-algorithm { 3des | aes { 128 | 192 | 256 } | des |
null } command to specify the encryption algorithm for the ESP protocol.
By default, no encryption algorithm is used for ESP. If encryption is not
required, specify null.
5. Run encapsulation-mode transport
A packet encapsulation mode is specified for the security protocol.
By default, the packet encapsulation mode is tunnel.

Currently, only the transport mode is supported on the device.

In transport mode, the packet encryption device and decryption device must be the originator and
receiver of packets.
The MD5, SHA-1, DES and 3DES algorithms are not recommended because they cannot meet
your security defense requirements.
6. Run quit

7. Run commit
Step 2 Configure an IPSec SA.

1. Run ipsec sa sa-name
An IPSec SA is created and the IPSec SA view is displayed.
By default, no IPSec SA exists in the system.

2. Run proposal proposal-name
The IPSec proposal is bound to the IPSec SA.
By default, an IPSec policy does not reference any IPSec proposal.
An IPSec can use only one IPSec proposal. To bind a new IPSec proposal to the IPSec SA, delete
the original IPSec proposal.
3. Run sa spi { inbound | outbound } { ah | esp } spi-number
An SPI is configured for the SA.
– An SPI uniquely identifies an SA. Each SA must be configured with an inbound SPI and an
outbound SPI. The outbound SPI on the local end must be the same as the inbound SPI on the
remote end.
– The security protocol (AH or ESP) you select when configuring the SPI must be the same as
that used in the IPSec proposal bound to the SA.
4. Configure a key according to the security protocol used in the IPSec proposal bound to
the SA.
– If the AH protocol is used, you can configure an authentication key that is a
hexadecimal number or a character string.
n Run the sa authentication-hex { inbound | outbound } ah [ cipher ] hex-
string command to configure a hexadecimal authentication key.
n Run the sa string-key { inbound | outbound } ah [ cipher ] string-key
command to configure a character string as the authentication key.
– If the ESP protocol is used, you can run one of the following commands to
configure the authentication key or the encryption key. You can also configure both
the authentication key and encryption key. If the two keys are configured at the
same time, they can only be hexadecimal keys.

n Run the sa authentication-hex { inbound | outbound } esp [ cipher ] hex-

n Run the sa string-key { inbound | outbound } esp [ cipher ] string-key
n Run the sa encryption-hex { inbound | outbound } esp [ cipher ] hex-string
command to configure a hexadecimal encryption key.
– The security protocol (AH or ESP) you select when configuring the key must be the same as
– The outbound key on the local end must be the same as the inbound key on the remote end.
– The IPSec peers must use the authentication or encryption key in the same format. For
example, if the key on one end is a character string but the key on the other end is a
hexadecimal number, the IPSec tunnel cannot be set up.
– If you configure multiple keys in different formats, the last configured key takes effect.
5. Run quit
6. Run commit
----End
3.8.11.2 Configuring PIM IPSec
Context
On a multicast network, multicast devices may be attacked by forged PIM protocol messages.
As a result, multicast data forwarding between multicast devices is interrupted. To protect
multicast devices against such attacks, configure PIM IPSec on the multicast devices to
encrypt and authenticate PIM protocol messages they send and receive.
When a Huawei device connects to a non-Huawei device that can only encrypt and
authenticate PIM Hello messages, configure the Huawei device to encrypt and authenticate
only PIM Hello messages.
A device running PIM IPSec processes PIM protocol messages as follows:
l Encapsulates PIM protocol messages with an IPSec header before sending the messages.
l Drops PIM protocol messages that are not protected by IPSec or fail the authentication.
If PIM IPSec is not configured on a device, the device drops PIM protocol messages that are
protected by IPSec.
l PIM IPSec can be configured in the PIM view or interface view. The configuration made in the PIM
view takes effect globally, and the configuration made in the interface view takes effect only on that
interface. If PIM IPSec is configured in both the PIM view and interface view, the configuration in
the interface view takes precedence. If PIM IPSec is not configured on an interface, the interface
uses the configuration made in the PIM view.
l To ensure normal multicast service forwarding, you are advised to configure PIM IPSec on all the
devices running PIM.

Procedure
l Configure global PIM IPSec.
a. Run system-view
c. Configure authentication for PIM messages.
You can configure the device to authenticate all the PIM unicast and multicast
messages or to authenticate only PIM Hello messages. Two IPSec peers must be
configured with the same authentication behavior for PIM messages. That is, both
the IPSec peers authenticate all the PIM messages or authenticate only PIM Hello
messages.
n Run the [ unicast-message ] ipsec sa sa-name command to authenticate PIM
messages sent and received by the device based on a specified SA.
You can configure one or both of the ipsec sa sa-name and unicast-message
ipsec sa sa-name commands on a device. The following rules apply:
○ If only ipsec sa sa-name is configured, the device authenticates only PIM
multicast messages using IPSec.
○ If only unicast-message ipsec sa sa-name is configured, the device
authenticates only PIM unicast messages using IPSec.
○ If the two commands are configured simultaneously, they both take effect.
That is, the device authenticates both PIM unicast and multicast messages
using IPSec.
n Run the hello ipsec sa sa-name command to authenticate PIM Hello messages
sent and received by the device based on a specified SA.
If the ipsec sa sa-name and hello ipsec sa sa-name commands are both configured,
the command configured later overrides the command configured earlier.
d. Run commit
l Configure PIM IPSec on an interface.
a. Run system-view

d. Configure authentication for PIM messages.
You can configure authentication for all the PIM messages or only PIM Hello
messages on an interface. Two IPSec peers must be configured with the same
authentication behavior for PIM messages. That is, both the IPSec peers
authenticate all the PIM messages or authenticate only PIM Hello messages.
n Run the pim ipsec sa sa-name command to authenticate PIM messages sent
and received on the interface based on a specified SA.
n Run the pim hello ipsec sa sa-name command to authenticate PIM Hello
messages sent and received on the interface based on a specified SA.
If the pim ipsec sa sa-name and pim hello ipsec sa sa-name commands are both
configured, the command configured later overrides the command configured
earlier.
e. Run commit
----End
3.8.11.3 Verifying the IPv4 PIM IPSec Configuration
Context
After configuring PIM IPSec, you can run the following commands in any view to check the
configuration of IPSec proposal, SA, and PIM IPSec, and IPSec packet statistics.
Procedure
l Run the display ipsec proposal [ name proposal-name | brief ] command to check
information about an IPSec proposal.
l Run the display ipsec sa [ sa-name ] [ brief ] command to check information about an
IPSec SA.
l Run the display ipsec statistics [ sa-name sa-name ] [ slot slot-number ] command to
check IPSec packet statistics.
[ interface-type interface-number | up | down ] [ verbose ] command to check the PIM
IPSec configuration on an interface.
----End
3.8.12 Configuring a Limit on the Number of IPv4 PIM-SM

Entries

Context
IPv4 PIM-SM allows you to limit the number of (S, G) and (*, G) entries separately. After a
specified limit is reached, new entries of the corresponding type are not created.
Procedure
Step 2 Run multicast global limit pim sm { star-group-number | source-group-number } limit-

count [ threshold-alarm upper-limit upper-limit-value lower-limit lower-limit-value ]
A limit on the number of PIM entries and alarm trigger and clear thresholds are set.
star-group-number indicates that the configuration takes effect for (*, G) entries. source-
group-number indicates that the configuration takes effect for (S, G) entries.
After the command is run:
Step 3 Run commit
----End

Run the display multicast global pim sm statistics command to check PIM entry restriction
and statistics.
3.8.13 Configuring a Device Not to Switch Multicast Traffic Back

to the Original Link After ECMP Link Switchover

You can configure a device on a PIM SM network not to switch multicast traffic back to the
original link after equal-cost multi-path routing (ECMP) link switchover. This will reduce
packet loss or excess packets during link switchover.
Before configuring a device not to switch multicast traffic back to the original link after
ECMP link switchover, complete the following tasks:
l Enable PIM-SM.
Context
If a link on a network running ECMP becomes faulty, multicast traffic on the link will be
switched to another ECMP link. After the fault is rectified, multicast traffic will be switched
back to the original link. During the switchback, the number of packets may increase or
packet loss may occur. To address this problem, you can configure a device not to switch
multicast traffic back to the original ECMP link after this link recovers. The device will
continue to transmit multicast traffic over the new link even if the original link has a higher
priority, and will only switch traffic back if the new link fails.
Perform the following procedure on the device running PIM-SM:
Procedure
Step 3 Run rpf ecmp non-reverse enable
The device is configured not to switch multicast traffic back to the original ECMP link after
link switchover.
By default, a device is configured to switch back multicast traffic to the original ECMP link
after the fault on this link is rectified.
Step 4 Run commit
----End
3.9 Configuring IPv4 Bidir-PIM
Context
The IPv4 Bidirectional Protocol Independent Multicast (Bidir-PIM) protocol implements
bidirectional multicast routing and data forwarding in an IPv4 PIM domain.

On the CE6875EI and CE6870EI, Layer 3 sub-interfaces and physical interfaces that are switched to Layer 3
mode using the undo portswitch command support Bidir-PIM. On switches of the other models, Layer 3
sub-interfaces and physical interfaces that are switched to Layer 3 mode using the undo portswitch
command do not support Bidir-PIM.
3.9.1 Configuring Basic IPv4 Bidir-PIM Functions
Context
Basic Bidir-PIM functions allow the switch to provide the Bidir-PIM service for hosts. A host
can send multicast data to other hosts in the same multicast group as a multicast source and
receive multicast data from other hosts as a receiver.
Before configuring basic Bidir-PIM functions, configure a unicast routing protocol to provide
reachable routes on the network.
The following configuration tasks are mandatory:
1. Enabling Bidir-PIM
2. Configuring an RP
The tasks of configuring a BSR administrative domain, adjusting C-RP parameters, and
adjusting C-BSR parameters are optional.
3.9.1.1 Enabling Bidir-PIM
Context
Enabling Bidir-PIM globally is the prerequisite for configuring other Bidir-PIM parameters.
Bidir-PIM inherits the neighbor discovery mechanism of Protocol Independent Multicast

Sparse Mode (PIM-SM) to reduce protocol complexity. Therefore, interfaces on a Bidir-PIM
network must run PIM-SM to set up PIM neighbor relationships.
Procedure
Step 2 Run multicast routing-enable
Step 3 Run pim

Step 4 Run bidir-pim

Bidir-PIM is enabled.
NOTICE
A multicast network does not allow routes that are destined for the same group address and
generated by different PIM protocols. Therefore, when you enable Bidir-PIM , the system
displays a message telling you that some multicast routes may be deleted. Determine whether
multicast services will be affected if multicast routing information is deleted.
Step 5 Run quit

Quit the PIM view.
1. Run quit
interface.
Step 9 Run pim sm

PIM-SM is enabled.
Step 10 Run commit
----End
3.9.1.2 Configuring an RP
Context
Like Protocol Independent Multicast Sparse Mode (PIM-SM), Bidir-PIM also requires a
rendezvous point (RP) on the network to forward multicast data as a transit device. When
configuring an RP for Bidir-PIM, specify the bidir keyword in the configuration command to
specify that the RP serves Bidir-PIM.
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 listening of Auto-RP messages.
NOTICE
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 Settings
Table 3-22 lists the default settings of C-BSR and C-RP parameters.
Table 3-22 Default settings of C-BSR and C-RP parameters

C-BSR priority 0
C-BSR hash mask length 30
BSR message Disabled

fragmentation

a static RP data with any group address)

a C-RP data with any group address)

C-RP priority 0
Interval for sending C-RP 60s

Hold time of C-RP 150s

Procedure
a. Run system-view

b. Run pim

c. Run static-rp rp-address [ basic-acl-number | acl-name acl-name ] [ preferred ]
bidir
A static RP address is specified, and the RP is configured to serve Bidir-PIM.
The preferred keyword indicates that the static RP takes precedence over a
dynamic RP.
All devices in a PIM domain must be configured with the same static RP address.
d. Run commit

a. Configure a C-BSR.
i. Run system-view
ii. Run pim
iii. Run c-bsr interface-type interface-number [ hash-length [ priority ] ]
A C-BSR is configured.
It is recommended that you configure the C-BSR on the device that aggregates
multicast data.
iv. (Optional) Run bsm semantic fragmentation
The BSR message fragmentation function is enabled.

BSR message fragmentation solves the problem in IP fragmentation, where 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 RP information.
v. Run commit
b. Configure a C-RP.
i. Run system-view
ii. Run pim
iii. 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 ]* bidir
A C-RP interface is specified and configured to serve Bidir-PIM.
It is recommended that you configure the C-RP on the device that aggregates
multicast data.
iv. Run c-rp load-splitting group-modulo
The device is configured to select the RP for a multicast group that users have
joined based on the modulo of the group address and the number of C-RPs.
By default, an RP is elected among C-RPs on a Bidir-PIM network according
to the following rules:
○ The C-RP with the longest mask length of the served group address range
matching the multicast group that users have joined wins.
○ If the mask length is the same, the C-RP with the highest priority
(smallest priority value) wins.
○ If the priority is the same, C-RPs use a hash algorithm to calculate their
hash values, and the C-RP with the largest hash value wins.
○ If all the preceding values are the same, the C-RP with the largest IP
address wins.
If the mask length and priority of C-RPs are the same, C-RPs use the multicast
group that users have joined, their C-RP addresses, and C-RP address masks to
calculate hash values. The C-RP with the largest hash value becomes the RP
that serves the multicast group. This RP election method cannot evenly
distribute multicast groups to RPs. As a result, bandwidth cannot be evenly
allocated to multicast traffic, which may result in congestion on the multicast
network.
To solve the preceding problem, you can use the c-rp load-splitting group-
modulo command to configure the C-RPs to select the RP for a multicast
group that users have joined based on the modulo of the group address and the
number of C-RPs. This RP election method can evenly distribute multicast
groups to RRs to improve bandwidth efficiency on the multicast network. It is
only applicable to networks with multiple C-RPs serving contiguous multicast
group addresses.

An RP can serve multiple multicast groups simultaneously, but each multicast group
can be associated with only one RP.
v. Run commit
c. (Optional) Configure a BSR boundary.
i. Run system-view
ii. Run interface interface-type interface-number
iii. On an Ethernet interface, run undo portswitch
Alternatively, if configuration information supported by both Layer 2 and
Layer 3 interfaces exists (for example, mode lacp and lacp system-id
configurations), no configuration that is not supported after the working mode
of the interface is switched can exist. If unsupported configurations exist on
the interface, delete the configurations first and then run the undo portswitch
command.
If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo
portswitch batch interface-type { interface-number1 [ to interface-number2 ] }
&<1-10> command in the system view to switch these interfaces to Layer 3 mode in
batches.
iv. For a Layer 3 sub-interface, run the following commands to configure
termination of single-tagged packets on it.
1) Run quit
2) Run interface interface-type interface-number.subinterface-number
number on an Ethernet interface that has been switched to the Layer 3
mode.
3) Run dot1q termination vid vid
By default, the termination of Dot1q packets is not configured on a Layer
3 sub-interface.
v. Run pim bsr-boundary [ incoming ]
A BSR service boundary is configured.

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 domain.
vi. Run commit
l Enable listening of Auto-RP messages.
a. Run system-view
b. Run pim
c. Run auto-rp listening enable
Listening of Auto-RP messages is enabled.
d. Run commit
----End
3.9.1.3 (Optional) Configuring a BSR Administrative Domain
Context
To facilitate PIM domain management, a PIM network is divided into multiple bootstrap
router (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.
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
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 interface interface-type interface-number

3. On an Ethernet interface, run undo portswitch
configurations (for example, shutdown and description configurations). Alternatively, if
configuration information supported by both Layer 2 and Layer 3 interfaces exists (for
example, mode lacp and lacp system-id configurations), no configuration that is not
supported after the working mode of the interface is switched can exist. If unsupported
configurations exist on the interface, delete the configurations first and then run the undo
portswitch command.
interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system
view to switch these interfaces to Layer 3 mode in batches.
4. For a Layer 3 sub-interface, run the following commands to configure termination of
single-tagged packets on it.
a. Run quit
b. Run interface interface-type interface-number.subinterface-number
The subinterface-number parameter must specify a Layer 3 sub-interface number
on an Ethernet interface that has been switched to the Layer 3 mode.
c. Run dot1q termination vid vid
interface.
5. Run multicast boundary group-address { mask | mask-length }
The boundary of the BSR administrative domain is configured.
Multicast packets that belong to the BSR administrative domain cannot traverse the boundary.
6. 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

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.9.1.4 (Optional) Adjusting C-RP Control Parameters
Context
When a candidate rendezvous point (C-RP) is configured on an interface, the C-RP
periodically sends Advertisement messages to a bootstrap router (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.
a. Run system-view

b. Run pim

c. Run c-rp priority priority
The C-RP priority is configured.

d. Run c-rp advertisement-interval interval
The interval for sending Advertisement messages is configured.

e. Run c-rp holdtime interval
The time period to hold the Advertisement messages received from the C-RP is
configured.
f. Run commit

l Configure the valid C-RP address range on the BSR.
a. Run system-view

b. Run pim

c. Run c-rp 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.
d. Run commit
----End
3.9.1.5 (Optional) Adjusting C-BSR Control Parameters
Context
Candidate bootstrap routers (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.
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.
Default Settings
Table 3-23 lists the default settings of the C-BSR.
Table 3-23 Default settings of the C-BSR

Interval for sending 60s

Bootstrap messages
Holdtime of Bootstrap 130s

messages
Procedure
l Configure parameters contained in a Bootstrap message for a C-BSR.
a. Run system-view
b. Run pim
c. Run c-bsr priority priority
The priority of the C-BSR is configured.
d. Run c-bsr hash-length priority
The hash mask length of the C-BSR is configured.
e. Run c-bsr interval interval
The interval for the BSR to send Bootstrap messages is configured.
f. Run c-bsr holdtime interval
The holdtime of the Bootstrap message received from the BSR is configured.
g. Run commit
l Configure a valid BSR address range on a PIM device.
a. Run system-view

b. Run pim
c. Run bsr-policy { basic-acl-number | acl-name acl-name }
The range of valid BSR addresses is configured.
d. Run commit
----End
3.9.1.6 Verifying the Basic IPv4 Bidir-PIM Function Configuration
Prerequisites
After basic Bidir-PIM functions are configured, you can check information about the BSR,
RP, PIM interfaces, PIM neighbors, and PIM routing table.
Procedure
l Run the display pim bsr-info command to check BSR information.
l Run the display pim rp-info [ group-address ] command to check RP information.
[ verbose ] command to check PIM information on interfaces.
number | verbose ] * command to check PIM neighbor information.
l Run either of the following commands to check PIM routing information:
mask } ] ] { rpf-interface interface-type interface-number | mode bidir } *
[ outgoing-interface { include | exclude | match } { interface-type interface-
number | none } | flags flag-value | fsm ] * [ outgoing-interface-number
[ number ] ]
– display pim routing-table brief [ group-address [ mask { group-mask-length |
incoming-interface { interface-type interface-number | register } ] *
----End
3.9.2 Adjusting Control Parameters for a Multicast Source in IPv4

Bidir-PIM
Context
After a PIM device receives a multicast packet sent to group G, it starts a timer for the (*, G)
entry and sets the timer to the multicast source lifetime. If the device receives a packet sent to

the group before the timer expires, it resets the timer. If the device does not receive any
multicast packet sent to the group within the lifetime, it considers the corresponding (*, 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.
Default Settings
Table 3-24 lists default settings of multicast source control parameters.


multicast source
Source address filtering No policy configured (Multicast data from all sources is
policy accepted.)
Procedure
Step 2 Run pim
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
1000 to 2000 1000 seconds
2000 to 8000 2000 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.
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 (*, 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.

l display pim routing-table [ group-address [ mask { group-mask-length | group-
mask } ] ] { rpf-interface interface-type interface-number | mode bidir } * [ outgoing-
interface { include | exclude | match } { interface-type interface-number | none } |
l display pim routing-table brief [ group-address [ mask { group-mask-length | group-
mask } ] | source-address [ mask { source-mask-length | source-mask } ] | incoming-
interface { interface-type interface-number | register } ] *

Relationships in IPv4 Bidir-PIM
Context
PIM devices establish PIM neighbor relationships by exchanging Hello messages.
You can configure the Hello message control parameters and neighbor filtering function in
either sequence.

3.9.3.1 Adjusting Control Parameters for Hello Messages
Context
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
Default Settings
Table 3-25 lists default settings of control parameters for Hello messages.
Table 3-25 Default settings of control parameters for Hello messages


messages

messages
Procedure
a. Run system-view
b. Run pim
e. Run commit
a. Run system-view



i. Run quit
sub-interface.


g. Run commit
----End
3.9.3.2 Configuring PIM Neighbor Filtering

Context
The switch supports neighbor filtering policies to ensure secure and effective multicast
transmission in a PIM 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
1. Run quit
interface.
Step 5 Run pim neighbor-policy { basic-acl-number | acl-name acl-name }

The range of valid neighbor addresses is configured.
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.
The device is configured to receive only Hello messages that contain Generation IDs.
Step 7 Run commit
----End

Neighbor Relationships in IPv4 Bidir-PIM
Prerequisites
After the neighbor control parameters are adjusted, you can check information about PIM
interfaces and PIM neighbors.
Procedure
number | verbose ] * command to check PIM neighbor information.
----End
3.9.4 Adjusting Control Parameters for DF Election in IPv4 Bidir-

PIM
Context
After PIM devices obtain rendezvous point (RP) information, they start a designated
forwarder (DF) election on the shared network segment.
You can configure the interval between Offer messages, interval between Backoff messages,
and DF election robustness variable in any sequence.

Each DF election control parameter must be set to the same value on a shared network segment.
Otherwise, the DF election may fail.
3.9.4.1 Configuring the Interval Between Offer Messages
Context
Devices on a Bidir-PIM shared network segment exchange Offer messages for designated
forwarder (DF) election. When a device obtains rendezvous point (RP) information, it sends
an Offer message to the shared network segment and starts a timer, with the value set to the
configured interval between Offer messages. Before the timer expires:
l If the device receives an Offer message carrying a better routing information to the RP,
the device stops sending Offer messages.
l If the device receives no Offer message or receives Offer messages carrying inferior
routing information to the RP, the device resets the timer when the timer expires and
continues sending Offer messages.
The interval between Offer messages can be configured in the PIM view or interface view. If you
configure this parameter in both the PIM view and interface view, the configuration in the interface view
takes effect.
Default Settings
Table 3-26 provides the default interval between Offer messages.
Table 3-26 Default interval between Offer messages

Interval between Offer 100 ms

messages
Procedure
a. Run system-view
b. Run pim
c. Run offer-interval interval
The interval between Offer messages is set.
d. Run commit

l Interface configuration
a. Run system-view
i. Run quit
sub-interface.
e. Run pim offer-interval interval
The interval between Offer messages is set.
f. Run commit
----End
3.9.4.2 Configuring the Interval Between Backoff Messages
Context
On a Bidir-PIM network, the elected designated forwarder (DF) sends a Backoff message
when it receives a superior Offer message. If the DF does not receive any Offer within the

interval for sending the next Backoff message, it sends a Pass message to notify all the
multicast devices that a new DF appears.
The interval between Backoff messages can be configured in the PIM view or interface view. If you
takes effect.
Default Settings
The default interval between Backoff messages is 1s.
Procedure
a. Run system-view
b. Run pim
c. Run backoff-interval interval
The interval between Backoff messages is configured.
d. Run commit
a. Run system-view

i. Run quit
sub-interface.
e. Run pim backoff-interval interval
The interval between Backoff messages is configured.

f. Run commit
----End
3.9.4.3 Configuring the DF Election Robustness Variable
Context
Devices on a Bidir-PIM shared network segment exchange Offer messages for designated
forwarder (DF) election. The DF election robustness variable is used in a DF election in the
following way:
l If a device does not receive any Offer message from other devices after sending Offer
messages robustness variable times, it considers itself as the DF.
l If the device receives an Offer message from a neighbor with a smaller route metric to
the RP, it stops participating in the DF election for a period (Time period = Robustness
variable x Interval between Offer messages). This suppression period gives the neighbor
a chance to be elected as the DF.
l If the DF's route metric to the RP address increases, the DF sends Win messages at
variable intervals to announce the new metric, for robustness variable times. If a device
has a better route metric than the DF's, the device responds with an Offer message to
trigger a new DF election.
The DF election robustness variable can be configured in the PIM view or interface view. If you
takes effect.
Default Settings
Table 3-27 provides the default DF election robustness variable.

Table 3-27 Default DF election robustness variable

DF election robustness 3
variable
Procedure
a. Run system-view
b. Run pim
c. Run election-robust-count robust-value
The DF election robustness variable is configured.
d. Run commit
a. Run system-view
i. Run quit


sub-interface.
e. Run pim election-robust-count robust-value
The DF election robustness variable is configured.
f. Run commit
----End
3.9.4.4 Verifying the Configuration of Control Parameters for DF Election in IPv4

Bidir-PIM
Prerequisites
After configuring control parameters for DF election, you can run the following commands to
check information about PIM interfaces, PIM neighbors, and DFs.
Procedure
l Run the display pim df-info [ rp rp-address | interface interface-type interface-number
| verbose ] * command to check information about DFs for an RP.
----End
3.9.5 Adjusting Control Parameters for Join/Prune Messages in

IPv4 Bidir-PIM
Context
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.

You can configure time parameters for Join/Prune messages, disable Join/Prune packaging,
set the Prune delay time, and configure Join information filtering in any sequence as required.
Context
A PIM device sends Join messages upstream to require forwarding of multicast data, and
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 message
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.
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.
Default Settings

Interval for sending Join/Prune messages 60s
Procedure
a. Run system-view

b. Run pim

c. Run timer join-prune interval

d. Run holdtime join-prune interval

e. Run commit

a. Run system-view


i. Run quit
sub-interface.
e. Run pim timer join-prune interval


f. Run pim holdtime join-prune interval

g. Run commit
----End
Context
message package. To prevent packets from being discarded, disable the Join/Prune message
packaging function.
Procedure
Step 2 Run pim
Step 4 Run commit
----End
Context
the time it performs the prune action is the sum of the lan-delay and override-interval.

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
Default Settings

LAN-delay 500 ms
Procedure
a. Run system-view
b. Run pim
e. Run commit
a. Run system-view

i. Run quit
sub-interface.
g. Run commit
----End
3.9.5.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

1. Run quit



interface.
Step 5 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 6 Run commit
----End
3.9.5.5 Verifying the Configuration of Control Parameters for Join/Prune

Messages in IPv4 Bidir-PIM
Prerequisites
After configuring Join/Prune message control parameters, you can run the following
commands to check information about PIM interfaces, statistics about PIM control messages,
and PIM routing table.

Procedure
prune | bsr | backoff | offer | pass | win } | interface interface-type interface-number ] *
command to check the number of PIM control messages sent and received by a PIM
device.
[ number ] ]
----End
3.9.6 Configuring IPv4 PIM BFD
Before configuring PIM BFD, complete the following tasks:
l Run the bfd command to enable BFD globally.

l Configure basic Bidir-PIM functions.
Context
Normally, if the current DF is faulty on the shared network segment, other PIM neighbors
participate in DF 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 DF 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.
Default Settings
Table 3-30 lists default settings of control parameters for PIM BFD messages.
Table 3-30 Default settings of control parameters for PIM BFD messages
Minimum sending interval 1000 ms

Minimum receiving 1000 ms

interval
Local detection multiplier 3
Procedure
1. Run quit
interface.
Step 5 Run pim bfd enable
PIM BFD is enabled.

Step 6 (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.
Step 7 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.9.7 Configuring IPv4 PIM Silent
Context
On the access layer, when the interface directly connected to a device is running the PIM
protocol, a PIM neighbor relationship can be established on this interface to process various
PIM packets. The configuration, however, has the security risks. 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 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.
NOTICE
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.
Procedure

1. Run quit



interface.
Step 5 Run pim silent
The PIM silent function is enabled.
Step 6 Run commit
----End

After PIM silent is configured, you can check information about the PIM interface.


3.9.8 Configuring IPv4 PIM IPSec
3.9.1.1 Enabling Bidir-PIM
Perform the configuration tasks in the listed sequence.
3.9.8.1 Configuring Basic IPSec Functions
Context
IPsec can be configured to prevent protocol packets from being intercepted or faked on a
simple network.
A security association (SA) must be established so that IPSec can protect protocol packets.
An SA is a unidirectional logical connection set up for security purpose and specifies the
elements used by two IPSec peers (two parties that use the IPSec protocol to protect protocol
packets between them). The elements of an SA include the following:
l Security protocol
l Authentication or encryption algorithm supported by the security protocol
l Protocol packet encapsulation mode
l Security parameter index (SPI) of the SA
l Authentication key or encryption key of the SA
The first three elements are specified in an IPSec proposal. To configure IPSec functions, first
configure an IPSec proposal on the IPSec peers, and then configure an SA.
Procedure
Step 1 Configure an IPSec proposal.
1. Run system-view
2. Run ipsec proposal proposal-name
An IPSec proposal is created and the IPSec proposal view is displayed.
3. Run transform { ah | esp }
A security protocol is specified for the IPSec proposal.
By default, the security protocol used by an IPSec proposal is the Encapsulation Security
Protocol (ESP).
4. An authentication or encryption algorithm is configured.
– If AH is used, you can only configure the AH-specific authentication algorithm
because AH only authenticates packets.
Run the ah authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 |
sha2-512 } command to specify the authentication algorithm for the AH protocol.

By default, no authentication algorithm is used for AH.

– When ESP is specified, ESP can authenticate, or encrypt and authenticate packets.
Configure the ESP-specific authentication or encryption algorithm.
n Run the esp authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 |
sha2-512 } command to specify the authentication algorithm for the ESP
protocol.
By default, no authentication algorithm is used for ESP.
n Run the esp encryption-algorithm { 3des | aes { 128 | 192 | 256 } | des |
null } command to specify the encryption algorithm for the ESP protocol.
By default, no encryption algorithm is used for ESP. If encryption is not
required, specify null.
5. Run encapsulation-mode transport
A packet encapsulation mode is specified for the security protocol.
By default, the packet encapsulation mode is tunnel.
Currently, only the transport mode is supported on the device.

In transport mode, the packet encryption device and decryption device must be the originator and
receiver of packets.
The MD5, SHA-1, DES and 3DES algorithms are not recommended because they cannot meet
your security defense requirements.
6. Run quit

7. Run commit
Step 2 Configure an IPSec SA.

1. Run ipsec sa sa-name
An IPSec SA is created and the IPSec SA view is displayed.
By default, no IPSec SA exists in the system.

2. Run proposal proposal-name
The IPSec proposal is bound to the IPSec SA.
By default, an IPSec policy does not reference any IPSec proposal.
An IPSec can use only one IPSec proposal. To bind a new IPSec proposal to the IPSec SA, delete
the original IPSec proposal.
3. Run sa spi { inbound | outbound } { ah | esp } spi-number
An SPI is configured for the SA.

– An SPI uniquely identifies an SA. Each SA must be configured with an inbound SPI and an
outbound SPI. The outbound SPI on the local end must be the same as the inbound SPI on the
remote end.
– The security protocol (AH or ESP) you select when configuring the SPI must be the same as
4. Configure a key according to the security protocol used in the IPSec proposal bound to
the SA.
– If the AH protocol is used, you can configure an authentication key that is a
hexadecimal number or a character string.
n Run the sa authentication-hex { inbound | outbound } ah [ cipher ] hex-
n Run the sa string-key { inbound | outbound } ah [ cipher ] string-key
– If the ESP protocol is used, you can run one of the following commands to
configure the authentication key or the encryption key. You can also configure both
the authentication key and encryption key. If the two keys are configured at the
same time, they can only be hexadecimal keys.
n Run the sa authentication-hex { inbound | outbound } esp [ cipher ] hex-
n Run the sa string-key { inbound | outbound } esp [ cipher ] string-key
n Run the sa encryption-hex { inbound | outbound } esp [ cipher ] hex-string
command to configure a hexadecimal encryption key.
– The security protocol (AH or ESP) you select when configuring the key must be the same as
– The outbound key on the local end must be the same as the inbound key on the remote end.
– The IPSec peers must use the authentication or encryption key in the same format. For
example, if the key on one end is a character string but the key on the other end is a
hexadecimal number, the IPSec tunnel cannot be set up.
– If you configure multiple keys in different formats, the last configured key takes effect.
5. Run quit

6. Run commit
----End
3.9.8.2 Configuring PIM IPSec
Context
On a multicast network, multicast devices may be attacked by forged PIM protocol messages.
As a result, multicast data forwarding between multicast devices is interrupted. To protect

multicast devices against such attacks, configure PIM IPSec on the multicast devices to
encrypt and authenticate PIM protocol messages they send and receive.
When a Huawei device connects to a non-Huawei device that can only encrypt and
authenticate PIM Hello messages, configure the Huawei device to encrypt and authenticate
only PIM Hello messages.
A device running PIM IPSec processes PIM protocol messages as follows:

l Encapsulates PIM protocol messages with an IPSec header before sending the messages.
l Drops PIM protocol messages that are not protected by IPSec or fail the authentication.
If PIM IPSec is not configured on a device, the device drops PIM protocol messages that are
protected by IPSec.
l PIM IPSec can be configured in the PIM view or interface view. The configuration made in the PIM
view takes effect globally, and the configuration made in the interface view takes effect only on that
interface. If PIM IPSec is configured in both the PIM view and interface view, the configuration in
the interface view takes precedence. If PIM IPSec is not configured on an interface, the interface
uses the configuration made in the PIM view.
l To ensure normal multicast service forwarding, you are advised to configure PIM IPSec on all the
devices running PIM.
Procedure
l Configure global PIM IPSec.
a. Run system-view

b. Run pim

c. Configure authentication for PIM messages.
You can configure the device to authenticate all the PIM unicast and multicast
messages or to authenticate only PIM Hello messages. Two IPSec peers must be
configured with the same authentication behavior for PIM messages. That is, both
the IPSec peers authenticate all the PIM messages or authenticate only PIM Hello
messages.
n Run the [ unicast-message ] ipsec sa sa-name command to authenticate PIM
messages sent and received by the device based on a specified SA.
You can configure one or both of the ipsec sa sa-name and unicast-message
ipsec sa sa-name commands on a device. The following rules apply:
○ If only ipsec sa sa-name is configured, the device authenticates only PIM
multicast messages using IPSec.
○ If only unicast-message ipsec sa sa-name is configured, the device
authenticates only PIM unicast messages using IPSec.
○ If the two commands are configured simultaneously, they both take effect.
That is, the device authenticates both PIM unicast and multicast messages
using IPSec.
n Run the hello ipsec sa sa-name command to authenticate PIM Hello messages
sent and received by the device based on a specified SA.

If the ipsec sa sa-name and hello ipsec sa sa-name commands are both configured,
the command configured later overrides the command configured earlier.
d. Run commit

l Configuring PIM IPSec on an interface
a. Run system-view


d. Configure authentication for PIM messages.
You can configure authentication for all the PIM messages or only PIM Hello
messages on an interface. Two IPSec peers must be configured with the same
authentication behavior for PIM messages. That is, both the IPSec peers
authenticate all the PIM messages or authenticate only PIM Hello messages.
n Run the pim ipsec sa sa-name command to authenticate PIM messages sent
and received on the interface based on a specified SA.
n Run the pim hello ipsec sa sa-name command to authenticate PIM Hello
messages sent and received on the interface based on a specified SA.
If the pim ipsec sa sa-name and pim hello ipsec sa sa-name commands are both
configured, the command configured later overrides the command configured
earlier.
e. Run commit
----End

3.9.8.3 Verifying the IPv4 PIM IPSec Configuration
Context
After configuring PIM IPSec, you can run the following commands in any view to check the
configuration of IPSec proposal, SA, and PIM IPSec, and IPSec packet statistics.
Procedure
l Run the display ipsec proposal [ name proposal-name | brief ] command to check
information about an IPSec proposal.
l Run the display ipsec sa [ sa-name ] [ brief ] command to check information about an
IPSec SA.
l Run the display ipsec statistics [ sa-name sa-name ] [ slot slot-number ] command to
check IPSec packet statistics.
[ verbose ] command to check the PIM IPSec configuration on an interface.
----End
3.9.9 Configuring a Limit on the Number of IPv4 Bidir-PIM

Entries
Context
IPv4 Bidir-PIM allows you to limit the number of (*, G) entries. After a specified limit is
reached, new (*, G) entries cannot be created.
Procedure
Step 2 Run multicast global limit bidir-pim star-group-number limit-count [ threshold-alarm
upper-limit upper-limit-value lower-limit lower-limit-value ]
A limit on the number of PIM entries and alarm trigger and clear thresholds are set. After the
command is run:


Step 3 Run commit
----End

Run the display multicast global bidir-pim statistics command to check PIM entry
restriction and statistics.
3.10 Maintaining IPv4 PIM-DM
3.10.1 Clearing Statistics About IPv4 PIM Control Packets
Context
To re-collect statistics about PIM control packets, clear the existing statistics. This operation
does not affect normal running of PIM.
NOTICE
Statistics about PIM control packets on an interface cannot be restored after you clear them.
Exercise caution when clearing the statistics.
Procedure
l Run the reset pim control-message counters [ interface interface-type interface-
number ] command in the user view to clear statistics about PIM control packets on
interfaces.
----End
3.10.2 Monitoring the IPv4 PIM-DM Running Status
Context
During routine maintenance, you can run the following commands in any view to monitor the
PIM running status.
Procedure
l Run the display pim claimed-route [ source-address ] command to check unicast routes
used by PIM.

command to check the number of sent and received PIM control messages.
[ number ] ]
l Run the display pim invalid-packet [ interface interface-type interface-number |
message-type { assert | hello | join-prune | graft | graft-ack | state-refresh } ] *
command to check the statistics about the invalid PIM packets received by the device.
l Run the display multicast global { pim sm | pim dm | bidir-pim | all } statistics
command to check PIM entry restriction and statistics.
----End
3.11 Maintaining IPv4 PIM-SM
Context
To re-collect 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.
NOTICE
Procedure
l Run the reset pim [ vpn-instance vpn-instance-name | all-instance ] control-message
counters [ interface interface-type interface-number ] command in the user view to
clear statistics about PIM control packets on an interface.
----End

3.11.2 Clearing the PIM Status of the Specified Downstream

Interfaces in IPv4 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.
NOTICE
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 [ vpn-instance vpn-instance-name ] routing-table group group-address
mask { group-mask-length | group-mask } source source-address interface interface-
type interface-number command in the user view.
You can also run the reset pim [ vpn-instance vpn-instance-name ] routing-table all command in
the user view to reset PIM status of downstream interfaces in all PIM routing entries.
----End
3.11.3 Clearing IPSec Packet Statistics
Context
To view accurate statistics about IPSec packets within a period, clear the existing statistics
first.
NOTICE
IPSec packet statistics cannot be restored after they are cleared. Confirm the action before you
run the following command.
Procedure
l Run the reset ipsec statistics [ sa-name sa-name ] [ slot slot-number ] command in the
user view to clear IPSec packet statistics.
----End
3.11.4 Monitoring the IPv4 PIM-SM Running Status

Context
During routine maintenance, you can run the following commands in any view to monitor the
PIM running status.
Procedure
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] claimed-route
[ source-address ] command to check unicast routes used by PIM.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] bfd session
[ interface interface-type interface-number | neighbor neighbor-address ] * command to
check the PIM BFD session.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] 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.
counters message-type { probe | register | register-stop | crp }
counters [ message-type { assert | hello | join-prune | bsr } | interface interface-
type interface-number ] *
[ interface-type interface-number | up | down ] [ verbose ] command in any view to
check PIM information on an interface.
check information about the PIM neighbor.
number [ number ] ]
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] rp-info [ group-
address ] command to check information about RPs of the multicast group.
----End

3.12 Maintaining IPv4 Bidir-PIM
Context
To re-collect statistics about PIM control packets, clear the existing statistics. This operation
does not affect normal running of PIM.
NOTICE
Procedure
l Run the reset pim control-message counters [ interface interface-type interface-
number ] command in the user view to clear statistics about PIM control packets on
interfaces.
----End
3.12.2 Clearing the PIM Status of the Specified Downstream

Interfaces in IPv4 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.
NOTICE
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.

You can also run the reset pim routing-table all command in the user view to reset PIM status of
downstream interfaces in all PIM routing entries.
----End
3.12.3 Clearing IPSec Packet Statistics
Context
To view accurate statistics about IPSec packets within a period, clear the existing statistics
first.
NOTICE
IPSec packet statistics cannot be restored after they are cleared. Confirm the action before you
run the following command.
Procedure
l Run the reset ipsec statistics [ sa-name sa-name ] [ slot slot-number ] command in the
user view to clear IPSec packet statistics.
----End
3.12.4 Monitoring the IPv4 Bidir-PIM Running Status
Context
During routine maintenance, you can run the following commands in any view to check the
PIM running status.
Procedure
l Run the display pim claimed-route [ source-address ] command to check unicast
routing information used for PIM.
l Run the display pim bfd session [ interface interface-type interface-number | neighbor
neighbor-address ] * command to check information about PIM BFD sessions.
l Run the display pim bsr-info command to check the BSR configuration.
prune | bsr | backoff | offer | pass | win } | interface interface-type interface-number ] *
command to check the statistics about PIM control messages sent and received by a PIM
device.


[ number ] ]
l Run the display pim rp-info [ group-address ] command to check information about
RPs for a multicast group.
l Run the display pim invalid-packet [ interface interface-type interface-number |
message-type { assert | bsr | hello | join-prune | offer | backoff | win | pass } ] *
command to check the statistics about invalid PIM control messages received by a PIM
device.
l Run the display pim df-info [ rp rp-address | interface interface-type interface-number
| verbose ] * command to check information about DFs for an RP.
----End
3.13 Configuration Examples for IPv4 PIM

3.13.1 Example for Configuring Basic IPv4 PIM-DM Functions
Figure 3-25 shows a small-scale network with densely distributed users. Host A and Host B
need to receive multicast data from the multicast source (Source).

Figure 3-25 Basic PIM-DM network

PIM-DM
10GE1/0/2
SwitchA
VLANIF20
4
10.110.1.1/24
/0 30 1/2
E1 F .
G NI 8.1
10 LA .16
/3
10GE1/0/1
V 2
19
VLANIF10 HostA
4
192.168.5.1/24 Receiver
/0 30 2/2
E1 F .
192.168.5.2/24
G NI 8.1
VLANIF10 10.110.2.1/24
/3
10 LA .16
Source 10GE1/0/1 VLANIF40
V 92
1 192.168.4.2/24 192.168.2.2/24 10GE1/0/2
VLANIF60 VLANIF80
SwitchD 10GE1/0/4 10GE1/0/3
10GE1/0/4 10GE1/0/1
10GE1/0/1 VLANIF60 SwitchE VLANIF80
VLANIF70 192.168.4.1/24 192.168.2.1/24
10.110.3.1/24 10GE1/0/2 SwitchB HostB
VLANIF50 Receiver
192.168.3.1/24 192.168.3.2/24
VLANIF50
10GE1/0/2 10.110.2.2/24
10GE1/0/1
VLANIF40
SwitchC
Since users are densely distributed on the network, PIM-DM can be deployed on the network
to provide multicast services for the user hosts. After PIM-DM is configured on the network,
all user hosts in a multicast group can receive multicast data sent from the multicast source to
the group.
1. Assign IP addresses to interfaces and configure a unicast routing protocol on the
switches. PIM is an intra-domain multicast routing protocol that depends on a unicast
routing protocol. It can work only when the unicast routing protocol works normally.
2. Enable multicast routing on all the switches that need to provide multicast services.
Multicast routing is the prerequisite for PIM-DM configuration.
3. Enable PIM-DM on all interfaces of the switches. Other PIM-DM functions can be
configured only after PIM-DM is enabled.
4. Enable IGMP on the interfaces connected to network segments of hosts. The IGMP
protocol maintains group memberships. The leaf switches use IGMP to maintain list of
group member ports.
Procedure
Step 1 Assign IP addresses to interfaces and configure a unicast routing protocol on the switches.
Configure IP addresses and masks for switch interfaces according to Figure 3-25. Configure
OSPF on the switches to implement IP interworking and dynamic updates of multicast routes
based on unicast routing.
# Add interfaces of SwitchA to VLANs. The configurations on SwitchB, SwitchC, SwitchD,
and SwitchE are similar to the configuration on SwitchA, and are not mentioned here.

[*HUAWEI] commit
[*SwitchA] commit
# Assign IP addresses to VLANIF interfaces on SwitchA. The configurations on SwitchB,

SwitchC, SwitchD, and SwitchE are similar to the configuration on SwitchA, and are not
mentioned here.
[*SwitchA] commit
# Configure a routing protocol on SwitchA. OSPF is used in this example. The configurations
on SwitchB, SwitchC, SwitchD, and SwitchE are similar to the configuration on SwitchA,
and are not mentioned here.
[~SwitchA] ospf
Step 2 Enable multicast routing on all switches and enable PIM-DM on all interfaces.
# Enable multicast routing globally and enable PIM-DM on all interfaces on SwitchA. The
configurations on SwitchB, SwitchC, SwitchD, and SwitchE are similar to the configuration
on SwitchA, and are not mentioned here.
[*SwitchA-Vlanif10] pim dm
[*SwitchA] commit
Step 3 Enable IGMP on the interfaces connected to network segments of hosts.

# Enable IGMP on the VLANIF interface of SwitchA connected to the network segment of
hosts. The configurations on SwitchB and SwitchC are similar to the configuration on
SwitchA, and are not mentioned here.


[*SwitchA] commit

# Run the display pim interface command on the switches to check the PIM configuration
and running status on switch interfaces. The following is an example of command output on
SwitchC. The State field is up, indicating that the PIM protocol is running on the interfaces,
and the PIM neighbor relationship has been established.
[~SwitchC] display pim interface
Interface State NbrCnt HelloInt DR-Pri DR-Address
Vlanif40 up 1 30 1 10.110.2.2 (local)
Vlanif50 up 1 30 1 192.168.3.2
# Run the display pim routing-table command to check the PIM routing tables on the
switches. You can see from the PIM routing tables that the multicast source (10.110.3.100/24)
sends multicast data to the group (225.1.1.1/24), and Host A and Host B have joined the
group. The command outputs on the switches are as follows:
(*, 225.1.1.1)
Protocol: pim-dm, Flag: WC
UpTime: 00:00:29
Upstream interface: NULL
Upstream neighbor: NULL
RPF prime neighbor: NULL
1: Vlanif20
Protocol: igmp, UpTime: 00:00:29, Expires: never
(10.110.3.100, 225.1.1.1)
Protocol: pim-dm, Flag: ACT
UpTime: 00:00:29
1: Vlanif20
Protocol: pim-dm, UpTime: 00:00:29, Expires: -
(*, 225.1.1.1)
UpTime: 00:00:29
1: Vlanif40
(10.110.3.100, 225.1.1.1)
UpTime: 00:00:29


Total number of downstreams: None
[~SwitchC] display pim routing-table
(*, 225.1.1.1)
UpTime: 00:00:29
1: Vlanif40
(10.110.3.100, 225.1.1.1)
UpTime: 00:01:25
1: Vlanif40
Protocol: pim-dm, UpTime: 00:01:25, Expires: -
(10.110.3.100, 225.1.1.1)
Protocol: pim-dm, Flag: LOC ACT
UpTime: 00:00:29
1: Vlanif30
Protocol: pim-dm, UpTime: 00:00:29, Expires: never
2: Vlanif60
[~SwitchE] display pim routing-table
(10.110.3.100, 225.1.1.1)
UpTime: 00:01:22
1: Vlanif50
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20 30

#
#
interface Vlanif10
ip address 192.168.5.1 255.255.255.0
pim dm
#
interface Vlanif20
ip address 10.110.1.1 255.255.255.0
pim dm
igmp enable
#
interface Vlanif30
ip address 192.168.1.1 255.255.255.0
pim dm
#
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
#
return
#
sysname SwitchB
#
vlan batch 40 80
#
#
interface Vlanif40
ip address 10.110.2.1 255.255.255.0
pim dm
igmp enable
#
interface Vlanif80
ip address 192.168.2.1 255.255.255.0
pim dm
#
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
#
return
#
sysname SwitchC
#

vlan batch 40 50
#
#
interface Vlanif40
ip address 10.110.2.2 255.255.255.0
pim dm
igmp enable
#
interface Vlanif50
ip address 192.168.3.1 255.255.255.0
pim dm
#
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 SwitchD
#
vlan batch 30 60 70
#
#
interface Vlanif30
ip address 192.168.1.2 255.255.255.0
pim dm
#
interface Vlanif60
ip address 192.168.4.1 255.255.255.0
pim dm
#
interface Vlanif70
ip address 10.110.3.1 255.255.255.0
pim dm
#
interface 10GE1/0/1
#
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 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
return
l SwitchE configuration file
#
sysname SwitchE
#

#
#
interface Vlanif10
ip address 192.168.5.2 255.255.255.0
pim dm
#
interface Vlanif50
ip address 192.168.3.2 255.255.255.0
pim dm
#
interface Vlanif60
ip address 192.168.4.2 255.255.255.0
pim dm
#
interface Vlanif80
ip address 192.168.2.2 255.255.255.0
pim dm
#
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
#
return
3.13.2 Example for Configuring IPv4 PIM-SM in the ASM Model
As shown in Figure 3-26, 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-26 Network diagram for configuring PIM-SM in the ASM model
Source
PIM-SM
SwitchA
4 10GE1/0/2
1 . 1/2 VLANIF20
. 10.110.1.1/24
68 30
9 2.1 NIF /0/3
1 LA E1 10GE1/0/1
V G
10 VLANIF10
24 192.168.5.1/24 HostA
10.110.3.1/24
. 1 .2/ Receiver
VLANIF80 68 30 192.168.5.2/24 SwitchB
10GE1/0/1 9 2.1 NIF /0/3 VLANIF10
1 LA E1 192.168.4.2/24 10GE1/0/1 192.168.2.1/24
V G VLANIF60 VLANIF90
Internet 10 10GE1/0/4 10GE1/0/1
192.168.4.1/24 10GE1/0/3
10GE1/0/2 VLANIF60 VLANIF90 10GE1/0/2
VLANIF70 10GE1/0/4 10GE1/0/2 192.168.2.2/24 VLANIF40
10.100.4.1/24 VLANIF50
192.168.3.2/24 SwitchE 10.110.2.1/24 HostB
SwitchD Receiver
192.168.3.1/24
VLANIF50 10GE1/0/1
10GE1/0/2 VLANIF40
SwitchC 10.110.2.2/24
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 Internet Group Management Protocol (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.
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 rendezvous point (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 bootstrap router (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-26, and configure
Open Shortest Path First (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.
# Add interfaces of SwitchA to VLANs. The configurations of SwitchB, SwitchC, SwitchD,
and SwitchE are similar to the configuration of Switch A, and are not provided here.
[*HUAWEI] commit
[*SwitchA] commit
# Assign IP addresses to VLANIF interfaces on SwitchA. The configurations of SwitchB,

SwitchC, SwitchD, and SwitchE are similar to the configuration of Switch A, and are not
provided here.
[*SwitchA] commit
of SwitchB, SwitchC, SwitchD, and SwitchE are similar to the configuration of Switch A, and
are not provided here.
[~SwitchA] ospf
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.
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 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.
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
Vlanif40 up 1 30 1 10.110.2.2 (local)
Vlanif50 up 1 30 1 192.168.3.2
# 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

Priority: 0
State: Elected
Scope: Not scoped
Uptime: 00:00:18
Next BSR message scheduled at: 00:01:42
C-RP Count: 1
Candidate AdminScoped BSR Count: 0
Candidate BSR Address: 192.168.4.2
Priority: 0
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 Number:1
Group/MaskLen: 225.1.1.0/24
RP: 192.168.4.2
Priority: 0
Uptime: 00:45:13
Expires: 00:02:17

BIDIR: N
PIM SM static RP Number:1
Static RP: 192.168.2.2
BIDIR: N
# 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:
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.
(*, 225.1.1.1)
RP: 192.168.4.2
UpTime: 00:13:46
1: Vlanif20
Protocol: igmp, UpTime: 00:13:46, Expires:-
(10.110.3.100, 225.1.1.1)
RP: 192.168.4.2
UpTime: 00:01:42
1: Vlanif20
Protocol: pim-sm, UpTime: 00:01:42, Expires:-

(*, 225.1.1.1)
RP: 192.168.4.2
UpTime: 00:10:12
1: Vlanif40
(10.110.3.100, 225.1.1.1)
RP: 192.168.4.2
Protocol: pim-sm, Flag:
UpTime: 00:00:42
Total number of downstreams: none


(*, 225.1.1.1)
RP: 192.168.4.2
UpTime: 00:10:12
1: Vlanif40
(10.110.3.100, 225.1.1.1)
UpTime: 00:01:25
1: Vlanif40

(10.110.3.100, 225.1.1.1)
RP: 192.168.4.2
Protocol: pim-sm, Flag: SPT LOC ACT
UpTime: 00:00:42
1: Vlanif30
2: Vlanif60

(*, 225.1.1.1)
RP: 192.168.4.2 (local)
UpTime: 00:13:16
Upstream interface: Register
1: Vlanif10
Protocol: pim-sm, UpTime: 00:13:16, Expires: 00:03:22
1: Vlanif90
(10.110.3.100, 225.1.1.1)
UpTime: 00:01:22


1: Vlanif50
----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
#
#
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
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
#
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
#
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 Vlanif60
c-rp Vlanif60 group-policy 2008
static-rp 192.168.2.2
#
return
3.13.3 Example for Configuring IPv4 PIM-SM in the SSM Model
In Figure 3-27, 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.
Figure 3-27 Network diagram for configuring PIM-SM in the SSM model
PIM-SM
SwitchA
SwitchF 192.168.1.1/24 10GE1/0/3
VLANIF30 VLANIF20
10GE1/0/2 10.110.1.1/24
S1 10GE1/0/2
10GE1/0/1 VLANIF30 10GE1/0/1
VLANIF70 192.168.1.2/24 VLANIF10 HostA
10.110.4.1/24 192.168.5.1/24
192.168.5.2/24
VLANIF10 10GE1/0/2
10.110.3.1/24 192.168.4.2/24 10GE1/0/1 192.168.2.1/24 VLANIF40
VLANIF80 VLANIF60 VLANIF90 10.110.2.1/24
10GE1/0/1 10GE1/0/4 10GE1/0/1
10GE1/0/3
VLANIF90
SwitchD 10GE1/0/4 192.168.2.2/24 SwitchB
VLANIF60 10GE1/0/2
S2 192.168.4.1/24 VLANIF50 SwitchE
192.168.3.2/24
10GE1/0/1
192.168.3.1/24 VLANIF40
VLANIF50 10.110.2.2/24
10GE1/0/2
HostB
SwitchC

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 Internet Group Management Protocol (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.
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 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-27, and configure
Open Shortest Path First (OSPF) on each switch to ensure that switches can communicate at
the network layer and can dynamically update routes through the unicast routing protocol.
# Add interfaces of SwitchA to VLANs. The configuration of SwitchB, SwitchC, SwitchD,
SwitchE, and SwitchF are similar to the configuration of SwitchA, and are not mentioned.
[*HUAWEI] commit
[*SwitchA] commit
# Assign IP addresses to VLANIF interfaces on SwitchA. The configuration of SwitchB,

SwitchC, SwitchD, SwitchE, and SwitchF are similar to the configuration of SwitchA, and are
not mentioned.


[*SwitchA] commit
# Configure a routing protocol on SwitchA. OSPF is used in this example. The configuration
of SwitchB, SwitchC, SwitchD, SwitchE, and SwitchF are similar to the configuration of
SwitchA, and are not mentioned.
[~SwitchA] ospf
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.
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.

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] 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:
Vlanif40 up 1 30 1 10.110.2.2 (local)
Vlanif50 up 1 30 1 192.168.3.2
# 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.
Total 2 (S, G) entries
(10.110.3.100, 232.1.1.1)
Protocol: pim-ssm, Flag: SPT ACT
UpTime: 00:13:46
1: Vlanif20
(10.110.4.100, 232.1.1.1)
UpTime: 00:00:42
1: Vlanif20

Total 1 (S, G) entry
(10.110.3.100, 232.1.1.1)
UpTime: 00:10:12
1: Vlanif40


(10.110.3.100, 232.1.1.1)
UpTime: 00:01:25
1: Vlanif40

(10.110.3.100, 232.1.1.1)
UpTime: 00:00:42
1: Vlanif60
Protocol: pim-ssm, UpTime: 00:00:42, Expires:-

(10.110.3.100, 232.1.1.1)
UpTime: 00:13:16
1: Vlanif10
Protocol: pim-ssm, UpTime: 00:13:16, Expires: 00:03:22
2: Vlanif50
3: Vlanif90
[~SwitchF] display pim routing-table

(10.110.4.100, 232.1.1.1)
UpTime: 00:13:16
1: Vlanif30
----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
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
#
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
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 SwitchF configuration file

#
sysname SwitchF
#
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
3.13.4 Example for Configuring Anycast RP Using IPv4 PIM
HostA and HostB in Network diagram for configuring Anycast RP using IPv4 PIM
receive VoD information in multicast mode. When the network is overloaded or traffic is
concentrated on a rendezvous point (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-28 Network diagram for configuring Anycast RP using IPv4 PIM
HostB 192.168.150.3/32
Loopback1
10.110.3.1/24
Source VLANIF31 SwitchD
10GE1/0/2
10 VL GE
.11 AN 1/0
10GE1/0/1
10
0. IF /1
1. 11
1/ 10GE1/0/3 VLANIF20
24
VLANIF30 192.168.2.2/24
192.168.3.2/24 Loopback0
192.168.150.1/32
SwitchA 192.168.2.1/24
VLANIF20
10GE1/0/2 10GE1/0/1
VLANIF10
192.168.1.1/24
192.168.1.2/24 192.168.3.1/24
VLANIF10 VLANIF30
Loopback1 10GE1/0/2 10GE1/0/1 SwitchB
192.168.150.2/32
PIM-SM
SwitchC 10GE1/0/3
VLANIF21
Loopback0 10.110.2.1/24
192.168.150.1/32
HostA
Configuring Anycast RP using IPv4 PIM 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 candidate bootstrap router (C-BSR) and
candidate rendezvous point (C-RP) on each interface, and enable Internet Group
Management Protocol (IGMP) on interfaces that connect the switch and hosts.
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-28, and
configure Open Shortest Path First (OSPF) on each switch to ensure that switches can
communicate.
# Add interfaces of SwitchC to VLANs. The configuration of SwitchA, SwitchB, and
SwitchD are similar to the configuration of SwitchC, and are not mentioned.
[~HUAWEI] sysname SwitchC
[*HUAWEI] commit
[~SwitchC] vlan batch 10 21 30
[*SwitchC] interface 10ge 1/0/1
[*SwitchC-10GE1/0/1] port link-type trunk
[*SwitchC-10GE1/0/1] port trunk allow-pass vlan 30
[*SwitchC-10GE1/0/1] quit
[*SwitchC-10GE1/0/2] port link-type trunk
[*SwitchC-10GE1/0/2] port trunk allow-pass vlan 10
[*SwitchC-10GE1/0/3] port default vlan 21
[*SwitchC] commit
# Assign IP addresses to interfaces on SwitchC. The configuration of SwitchA, SwitchB, and

SwitchD are similar to the configuration of SwitchC, and are not mentioned.
[~SwitchC] interface vlanif 10
[*SwitchC-Vlanif10] ip address 192.168.1.2 24
[*SwitchC-Vlanif10] quit
[*SwitchC] interface vlanif 21
[*SwitchC] interface loopback 0
[*SwitchC-LoopBack0] ip address 192.168.150.1 32
[*SwitchC-LoopBack0] quit
[*SwitchC-LoopBack1] ip address 192.168.150.2 32
[*SwitchC] commit
# Configure a routing protocol on SwitchC. OSPF is used in this example. The configuration
of SwitchA, SwitchB, and SwitchD are similar to the configuration of SwitchC, and are not
mentioned.
[~SwitchC] ospf
[*SwitchC-ospf-1] area 0
[*SwitchC-ospf-1-area-0.0.0.0] network 10.110.2.0 0.0.0.255
[*SwitchC-ospf-1-area-0.0.0.0] commit
[~SwitchC-ospf-1-area-0.0.0.0] quit
[~SwitchC-ospf-1] quit
Step 2 Configure basic multicast functions on each switch.

# Enable multicast routing on SwitchC and PIM-SM on interfaces. The configuration of
SwitchA, SwitchB, and SwitchD are similar to the configuration of SwitchC, and are not
mentioned here.
[~SwitchC] multicast routing-enable

[*SwitchC-Vlanif10] pim sm
[*SwitchC-LoopBack0] pim sm
[*SwitchC] commit
# 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.
[~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-Vlanif21] igmp enable
[*SwitchC-Vlanif21] commit
[~SwitchC-Vlanif21] quit
Step 3 Configure Anycast RP.

# On SwitchC and SwitchD, configure Loopback0 as an Anycast RP and specify the address
of Loopback1 as the local Anycast address. The configuration of SwitchD is similar to the
configuration of SwitchC, and is not mentioned.
[~SwitchC] pim
[~SwitchC-pim] anycast-rp 192.168.150.1
[*SwitchC-pim-anycast-rp-192.168.150.1] local-address 192.168.150.2
[*SwitchC-pim-anycast-rp-192.168.150.1] commit
[~SwitchC-pim-anycast-rp-192.168.150.1] quit
[~SwitchC-pim] quit
# Configure SwitchC and SwitchD as Anycast RP peers.

[~SwitchC-pim] anycast-rp 192.168.150.1
[~SwitchC-pim-anycast-rp-192.168.150.1] peer 192.168.150.3
[*SwitchC-pim-anycast-rp-192.168.150.1] commit
[~SwitchC-pim-anycast-rp-192.168.150.1] quit
[~SwitchC-pim] quit
[~SwitchD-pim] anycast-rp 192.168.150.1
[~SwitchD-pim-anycast-rp-192.168.150.1] peer 192.168.150.2
[*SwitchD-pim-anycast-rp-192.168.150.1] commit
[~SwitchD-pim-anycast-rp-192.168.150.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: 192.168.150.1 (local)
Priority: 0
Uptime: 00:45:19
Expires: 00:02:11
BIDIR: N
[~SwitchD] display pim rp-info
RP: 192.168.150.1 (local)
Priority: 0
Uptime: 02:27:56
Expires: 00:01:39
BIDIR: N
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: 192.168.150.1 (local)
Protocol: pim-sm, Flag: SPT 2MSDP ACT
UpTime: 00:00:38
1: Vlanif30

(*, 226.1.1.1)
RP: 192.168.150.1 (local)
UpTime: 00:01:25
1: Vlanif31
(10.110.1.2, 226.1.1.1)
RP: 192.168.150.1 (local)
UpTime: 00:00:02
1: Vlanif31
----End

Configuration Files
#
sysname SwitchA
#
vlan batch 10 to 11
#
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
pim sm
#
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
#
interface 10GE1/0/3
#
interface LoopBack0
ip address 192.168.150.1 255.255.255.255
pim sm
#
interface LoopBack1
ip address 192.168.150.2 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.150.1 0.0.0.0
network 192.168.150.2 0.0.0.0
#
pim
c-bsr LoopBack0
c-rp LoopBack0
anycast-rp 192.168.150.1
local-address 192.168.150.2
peer 192.168.150.3
#
return
#
sysname SwitchD
#
vlan batch 20 30 to 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 192.168.150.1 255.255.255.255
pim sm
#
interface LoopBack1
ip address 192.168.150.3 255.255.255.255
pim sm
#
ospf 1
area 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
network 192.168.150.1 0.0.0.0
network 192.168.150.3 0.0.0.0
#
pim
c-bsr LoopBack0
c-rp LoopBack0
anycast-rp 192.168.150.1
local-address 192.168.150.3
peer 192.168.150.2
#
return
3.13.5 Example for Configuring Basic IPv4 Bidir-PIM Functions
Figure 3-29 shows an enterprise campus network. A multicast protocol is required on the
network to allow multi-party video conferences among users connected to the network.

Figure 3-29 Network diagram for basic Bidir-PIM configurations
HostA HostB
192.168.1.1/24 192.168.2.1/24
VLANIF10 VLANIF20
10GE1/0/1 10GE1/0/1
Bidir-PIM network
SwitchA 10.1.1.1/24 10.1.2.1/24 SwitchB
VLANIF50 VLANIF60
10GE1/0/2 10GE1/0/2
10.1.2.2/24
10.1.1.2/24 SwitchE VLANIF60
VLANIF50 10GE1/0/2
10GE1/0/1
10GE1/0/3 10GE1/0/4
VLANIF70 VLANIF80
10.1.3.2/24 10.1.4.2/24
10GE1/0/2 10GE1/0/2
VLANIF70 VLANIF80
SwitchC 10.1.3.1/24 10.1.4.1/24 SwitchD
10GE1/0/1 10GE1/0/1
VLANIF30 VLANIF40
192.168.3.1/24 192.168.4.1/24
HostC HostD
If a multi-party video conferencing network runs Protocol Independent Multicast Sparse
Mode (PIM-SM) to provide multicast services for many users, switches on the network will
be overloaded because a lot of forwarding resources are consumed on the switches. To
conserve the forwarding resources on the switches, configure Bidir-PIM on this network. The
configuration roadmap is as follows:
1. Assign IP addresses to interfaces and configure a unicast routing protocol on the
switches. PIM is an intra-domain multicast routing protocol that depends on a unicast
routing protocol. It can work only when the unicast routing protocol works normally.
2. Enable Bidir-PIM on all the switches that need to provide multicast services. Other
Bidir-PIM functions can be configured only after Bidir-PIM is enabled.
3. Enable PIM-SM on all switch interfaces. Bidir-PIM uses the same neighbor discovery
mechanism as PIM-SM. PIM-SM must be enabled on interfaces so that neighbor
relationships can be set up between the switches.
4. Enable IGMP on the interfaces connected to network segments of the hosts. Then
receiver hosts can send Internet Group Management Protocol (IGMP) messages to join
or leave a group. The leaf switches use IGMP to maintain group memberships.
5. Configure a rendezvous point (RP) and configure it to serve Bidir-PIM. On a Bidir-PIM
network, an RP is the transit device for multicast data forwarding. An RP should be
deployed on a switch with multiple branches for multicast data forwarding, like SwitchE
in Figure 3-29.

Procedure
Step 1 Assign IP addresses to interfaces and configure a unicast routing protocol on the switches.
Open Shortest Path First (OSPF) on the switches to implement IP interworking between the
switches and enable the switches to dynamically update routes.
# Add interfaces of SwitchA to VLANs. The configurations on SwitchB, SwitchC, SwitchD,
and SwitchE are similar to the configuration on SwitchA, and are not mentioned here.
[*HUAWEI] commit
[*SwitchA] commit
# Assign IP addresses to VLANIF interfaces on SwitchA. The configurations on SwitchB,

SwitchC, SwitchD, and SwitchE are similar to the configuration on SwitchA, and are not
mentioned here.
[*SwitchA] commit
on SwitchB, SwitchC, SwitchD, and SwitchE are similar to the configuration on SwitchA,
and are not mentioned here.
[~SwitchA] ospf
Step 2 Enable Bidir-PIM globally and enable PIM-SM on all interfaces.

# Enable Bidir-PIM globally on all switches and enable PIM-SM on all interfaces. The
configurations on SwitchB, SwitchC, SwitchD, and SwitchE are similar to the configuration
on SwitchA, and are not mentioned here.
[*SwitchA] pim
[*SwitchA-pim] bidir-pim
[*SwitchA-pim] quit

Step 3 Enable IGMP on interfaces directly connected to network segments of hosts.

# Enable IGMP on interface of SwitchA connected to the network segment of HostA. The
configurations on SwitchB, SwitchC, and SwitchD are similar to the configuration on
Step 4 Configure an RP.

# Configure a candidate rendezvous point (C-RP) and a candidate bootstrap router (C-BSR)
on an interface of SwitchE and configure the C-RP to serve Bidir-PIM.
[~SwitchE] pim
[~SwitchE-pim] c-bsr vlanif 60
[*SwitchE-pim] c-rp vlanif 60 bidir
[*SwitchE-pim] commit
[~SwitchE-pim] quit

# Run the display pim bsr-info command on the switches to view BSR information. For
example, BSR information on SwitchA and SwitchE is displayed as follows. (The command
output on SwitchE also displays C-BSR information.)
[~SwitchA] display pim bsr-info
Priority: 0
State: Accept Preferred
Scope: Not scoped
Uptime: 00:05:57
Expires: 00:01:27
C-RP Count: 1
[~SwitchE] display pim bsr-info

Priority: 0
State: Elected
Scope: Not scoped
Uptime: 00:05:08
Next BSR message scheduled at: 00:00:06
C-RP Count: 1
Candidate AdminScoped BSR Count: 0
Candidate BSR Address: 10.1.2.2
Priority: 0
State: Elected
Scope: Not scoped
Wait to be BSR: 0
The preceding information shows that the addresses of the elected BSR and C-BSR are both
10.1.2.2, IP address of VLANIF60 on SwitchE.
# Run the display pim rp-info command on the switches to check RP information. For
example, RP information on SwitchA is as follows:
[~SwitchA] display pim rp-info


RP: 10.1.2.2
Priority: 0
Uptime: 00:10:49
Expires: 00:01:41
BIDIR: Y
The preceding information shows that the address of the elected RP is 10.1.2.2 (IP address of
VLANIF60 on SwitchE), and the elected RP serves Bidir-PIM.
# Run the display pim df-info command on the switches to check DF information. For
example, DF information on SwitchA and SwitchE is as follows:
[~SwitchA] display pim df-info
Total Number of DF = 2
RP: 10.1.2.2
Interface DF-Address DF-Uptime Rpf-Interface
Vlanif10 192.168.1.1(local) 00:25:01 N
Vlanif50 10.1.1.2 00:25:01 Y
[~SwitchE] display pim df-info
Total Number of DF = 4
RP: 10.1.2.2
Interface DF-Address DF-Uptime Rpf-Interface
Vlanif60 - - Y
Vlanif70 10.1.3.2(local) 00:31:44 N
Vlanif50 10.1.1.2(local) 00:31:44 N
Vlanif80 10.1.4.2(local) 00:31:44 N
# After HostA, HostB, HostC, and HostD join group 225.0.0.1 using IGMP, you can run the
display pim routing-table command on the switches to view the PIM routing table. For
example, the PIM routing table on SwitchA is as follows:
(*, 225.0.0.1)
RP: 10.1.2.2
Protocol: bidir-pim, Flag: WC ACT
UpTime: 00:36:47
Rpf interface: Vlanif50
1: Vlanif10
2: Vlanif50(RPF)
Protocol: bidir-pim, UpTime: 00:36:47, Expires: -
You can see that the routing entries are generated by Bidir-PIM, and multicast data sent from
the hosts (multicast sources) can be forwarded along the bidirectional RPT set up based on the
(*, 225.0.0.1) entry.
----End
Configuration Files
#
sysname SwitchA
#

vlan batch 10 50
#
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif50
ip address 10.1.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.1.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
pim
bidir-pim
#
return
#
sysname SwitchB
#
vlan batch 20 60
#
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif60
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.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
bidir-pim
#
return
#
sysname SwitchC
#
vlan batch 30 70
#

#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif70
ip address 10.1.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.1.3.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
bidir-pim
#
return
#
sysname SwitchD
#
vlan batch 40 80
#
#
interface Vlanif40
ip address 192.168.4.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif80
ip address 10.1.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.1.4.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
bidir-pim
#
return
#
sysname SwitchE
#
#
#

interface Vlanif50
ip address 10.1.1.2 255.255.255.0
pim sm
#
interface Vlanif60
ip address 10.1.2.2 255.255.255.0
pim sm
#
interface Vlanif70
ip address 10.1.3.2 255.255.255.0
pim sm
#
interface Vlanif80
ip address 10.1.4.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 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
network 10.1.4.0 0.0.0.255
#
pim
c-bsr Vlanif60
bidir-pim
c-rp Vlanif60 bidir
#
return
3.13.6 Example for Configuring IPv4 Bidir-PIM and IPv4 PIM-SM

on the Same Network
On the network shown in Figure 3-30, HostA needs to receive data for multicast group
225.1.1.1 through Bidir-PIM, and HostB needs to receive for multicast group 226.1.1.1
through Protocol Independent Multicast Sparse Mode (PIM-SM).

Figure 3-30 Bidir-PIM and PIM-SM on the same network

Loopback0
10.2.2.2/32
10GE1/0/1
Loopback0 VLANIF10
10.1.1.1/32 PIM network
10.110.1.1/24
0 /2
1/ 00 4 SwitchB
GE F1 1/2
Source 10 ANI 68.2. 10GE1/0/2 HostA
VL 2.1 VLANIF100 225.1.1.1
19
SwitchA 192.168.2.2/24
10GE1/0/1 10 10GE1/0/3
VLANIF30 VL GE1 VLANIF200
10GE1/0/1
10.110.3.1/24 19 ANI /0/3 192.168.3.2/24
2.1 F2 VLANIF20
68 00 10.110.2.1/24
.3.
1/2
4
SwitchC
HostB
226.1.1.1
Loopback0
10.3.3.3/32
Configure dynamic RPs to serve Bidir-PIM and PIM-SM on SwitchA and configure ACL
rules to define the range of multicast groups served by dynamic RPs. In this way, both Bidir-
PIM and PIM-SM can function on the network. The configuration roadmap is as follows:
1. Assign IP addresses to interfaces and configure a unicast routing protocol on each
switch.
2. Enable multicast routing on all the switches that provide multicast services.
3. Enable Bidir-PIM on all the switches that provide multicast services.
4. Enable PIM-SM on all interfaces of the switches that provide multicast services.
5. Enable Internet Group Management Protocol (IGMP) on switch interfaces directly
connected to hosts.
6. Configure the dynamic RP function. On SwitchA, configure dynamic RPs on different
interfaces to serve Bidir-PIM and PIM-SM respectively, and configure ACL rules to
define the range of multicast groups served by dynamic rendezvous points (RPs).
Procedure
Step 1 Assign IP addresses to interfaces and configure a unicast routing protocol on each switch.
OSPF on the switches to implement IP interworking between the switches and enable the
switches to dynamically update routes. The configurations of SwitchB and SwitchC are
similar to the configuration of SwitchA, and are not mentioned here.
# Add interfaces of SwitchA to VLANs. The configurations of SwitchB and SwitchC are
similar to the configuration of SwitchA, and are not mentioned here.
[*HUAWEI] commit


[*SwitchA] commit
# Assign IP addresses to interfaces of SwitchA. The configurations of SwitchB and SwitchC

are similar to the configuration of SwitchA, and are not mentioned here.
[*SwitchA] interface loopback0
[*SwitchA-LoopBack0] ip address 10.1.1.1 32
[*SwitchA-LoopBack0] quit
[*SwitchA] commit
# Configure unicast routing protocol OSPF on SwitchA. The configurations of SwitchB and
SwitchC are similar to the configuration of SwitchA, and are not mentioned here.
[~SwitchA] router id 10.1.1.1
[*SwitchA] ospf
Step 2 Enable multicast routing and Bidir-PIM on the switches.

# Enable multicast routing and Bidir-PIM on SwitchA. The configurations of SwitchB and
[*SwitchA] pim
[*SwitchA-pim] bidir-pim
[~SwitchA-pim] quit
Step 3 Enable PIM-SM on all the switch interfaces.

# Enable PIM-SM on all the interfaces of SwitchA. The configurations of SwitchB and

[*SwitchA-LoopBack0] pim sm
[*SwitchA] commit
Step 4 Enable IGMP on interfaces directly connected to network segments of hosts.

# Configure SwitchB.
[~SwitchB] interface vlanif 10
[~SwitchB-Vlanif10] igmp enable
[*SwitchB-Vlanif10] commit
[~SwitchB-Vlanif10] quit
# Configure SwitchC.
[~SwitchC-Vlanif20] igmp enable
Step 5 Configure the dynamic RP function.

# Configure different C-RP interfaces to serve Bidir-PIM and PIM-SM on SwitchA.
[*SwitchA-acl4-basic-2000] quit
[*SwitchA] acl number 2001
[*SwitchA-acl4-basic-2001] quit
[*SwitchA] pim
[*SwitchA-pim] c-bsr vlanif30
[*SwitchA-pim] c-rp loopback0 group-policy 2000 bidir
[*SwitchA-pim] c-rp vlanif30 group-policy 2001
[~SwitchA-pim] quit

# Run the display pim routing-table command to view the PIM routing table on each switch.
You can see from the routing tables that multicast source 10.110.3.100/24 sends data to
multicast groups 225.1.1.1/24 and 226.1.1.1/24, HostA joined group 225.1.1.1/24, and HostB
joined group 226.1.1.1/24. For example, the PIM routing tables on SwitchA and SwitchB are
as follows:
Total 2 (*, G) entries; 1 (S, G) entry
(*, 226.1.1.1)
RP: 10.110.3.1 (local)
UpTime: 03:05:41
1: Vlanif200
(10.110.3.100, 226.1.1.1)
RP: 10.110.3.1 (local)
UpTime: 00:06:27


1: Vlanif200
(*, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 03:00:42
Rpf interface: LoopBack0
1: Vlanif100
Protocol: bidir-pim, UpTime: 03:00:42, Expires: 00:02:48
2: LoopBack0(RPF)
(*, 225.1.1.1)
RP: 10.1.1.1
UpTime: 00:01:08
Rpf interface: Vlanif100
1: Vlanif10
2: Vlanif100(RPF)
According to the command output, HostA can receive data for group 225.1.1.1 through Bidir-
PIM, and HostB can receive data for group 226.1.1.1 through PIM-SM.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 30 100 200
#
router id 10.1.1.1
#
#
acl number 2000
#
acl number 2001
#
interface Vlanif30
ip address 10.110.3.1 255.255.255.0
pim sm
#
interface Vlanif100
ip address 192.168.2.1 255.255.255.0
pim sm
#
interface Vlanif200

ip address 192.168.3.1 255.255.255.0

pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface LoopBack0
ip address 10.1.1.1 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.1.1.1 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 Vlanif30
bidir-pim
c-rp Vlanif30 group-policy 2001
c-rp LoopBack0 group-policy 2000 bidir
#
return
#
sysname SwitchB
#
vlan batch 10 100
#
router id 10.2.2.2
#
#
interface Vlanif10
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif100
ip address 192.168.2.2 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface LoopBack0
ip address 10.2.2.2 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.2.2.2 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim

bidir-pim
#
return

#
sysname SwitchC
#
vlan batch 20 200
#
router id 10.3.3.3
#
#
interface Vlanif20
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif200
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/3
#
interface LoopBack0
ip address 10.3.3.3 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.3.3.3 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
bidir-pim
#
return
3.13.7 Example for Configuring IPv4 Layer 3 Multicast over M-

LAG
On the IPv4 network shown in Figure 3-31, the Layer 2 access switch (Switch) is dual-homed
to active-active VRRP gateways SwitchA and SwitchB through an M-LAG to enhance
network reliability. The receiver connected to Switch wants to receive the multicast video
program from the source.

Figure 3-31 Network diagram for IPv4 Layer 3 multicast over M-LAG configuration
Source
VLANIF 15
SwitchC 10GE1/0/3
VLANIF12 VLANIF 14
10GE1/0/1 10GE1/0/2
VLANIF 12 VLANIF 14
VLANIF 13
10GE1/0/1 VLANIF 13 10GE1/0/1
10GE1/0/6
10GE1/0/6
SwitchA SwitchB
10GE1/0/4~1/0/5
10GE1/0/2~1/0/3 Eth-Trunk 1 10GE1/0/2~1/0/3
Eth-Trunk 10 peer-link 1 Eth-Trunk 10
VLANIF 11 VLANIF 11
M-LAG
Eth-Trunk 20
10GE1/0/1~1/0/4
Switch
Peer-link
Layer 3 link
Receiver
Table 3-31 Device configuration list
Device Interface VLANIF Interface IP Address
SwitchA 10GE1/0/1 VLANIF 12 10.3.1.1/24
10GE1/0/6 VLANIF 13 10.5.1.1/24
Eth-Trunk 10 VLANIF 11 10.2.1.1/24
MEth0/0/0 – 10.1.1.1/24
SwitchB 10GE1/0/1 VLANIF 14 10.4.1.1/24
10GE1/0/6 VLANIF 13 10.5.1.2/24
Eth-Trunk 10 VLANIF 11 10.2.1.2/24
MEth0/0/0 – 10.1.1.2/24
SwitchC 10GE1/0/1 VLANIF 12 10.3.1.2/24
10GE1/0/2 VLANIF 14 10.4.1.2/24
10GE1/0/3 VLANIF 15 10.6.1.1/24

To meet the requirements, the M-LAG master and backup switches (SwitchA and SwitchB) must have both a
peer link and a direct Layer 3 link between them, and they must have the same multicast configuration.

1. Configure M-LAG and VRRP on SwitchA and SwitchB, and configure active-active
access on Switch to enhance reliability.
2. Configure a unicast routing protocol on SwitchA, SwitchB, and SwitchC to implement
IP interworking. Multicast routing works depending on unicast routing.
3. Enable PIM-SM and IGMP on VLANIF interfaces of SwitchA and SwitchB, and enable
PIM-SM on VLANIF interfaces of SwitchC, so that multicast forwarding entries can be
created on the switches.
4. Enable the PIM silent function on user-side VLANIF interfaces on SwitchA and
SwitchB, to ensure that SwitchA and SwitchB both act as DRs and send Join messages
to the RP.
5. On SwitchA and SwitchB, enable IGMP snooping in the VLANs corresponding to the
VLANIF interfaces to implement accurate multicast forwarding on the Layer 2 network.
6. Disable STP on the interfaces at both sides of the Layer 3 link between SwitchA and
SwitchB, and specify the VLAN that is not allowed on the peer-link. This ensures
normal multicast forwarding on the M-LAG.
Procedure
Step 1 Configure an M-LAG based on Virtual Spanning Tree Protocol (V-STP) and a VRRP group.
1. Configure a V-STP-based M-LAG.
# On SwitchA, configure a Dynamic Fabric Service (DFS) group, a peer-link, V-STP, an
M-LAG, the LACP M-LAG system priority and system ID, to set up a V-STP-based M-
LAG. The configuration on SwitchB is similar to the configuration on SwitchA. For
details, see its configuration file.
[*HUAWEI] commit
[~SwitchA] interface meth 0/0/0
[~SwitchA-MEth0/0/0] ip address 10.1.1.1 24
[*SwitchA-MEth0/0/0] quit
[*SwitchA] dfs-group 1
[*SwitchA-dfs-group-1] source ip 10.1.1.1
[*SwitchA-dfs-group-1] priority 150
[*SwitchA-dfs-group-1] quit
[*SwitchA] interface eth-trunk 1
[*SwitchA-Eth-Trunk1] trunkport 10ge 1/0/4 to 1/0/5
[*SwitchA-Eth-Trunk1] mode lacp-static
[*SwitchA-Eth-Trunk1] peer-link 1
[*SwitchA-Eth-Trunk1] quit
[*SwitchA] stp mode rstp
[*SwitchA] stp v-stp enable
[*SwitchA] vlan batch 11
[*SwitchA-Eth-Trunk10] mode lacp-static
[*SwitchA-Eth-Trunk10] port link-type trunk
[*SwitchA-Eth-Trunk10] port trunk allow-pass vlan 11
[*SwitchA-Eth-Trunk10] trunkport 10ge 1/0/2 to 1/0/3
[*SwitchA-Eth-Trunk10] dfs-group 1 m-lag 1
[*SwitchA-Eth-Trunk10] lacp m-lag priority 10

[*SwitchA-Eth-Trunk10] lacp m-lag system-id 00e0-fc00-0000

[*SwitchA] commit
# On Switch, create an Eth-Trunk and bind uplink interfaces to the Eth-Trunk.

[~HUAWEI] sysname Switch
[*HUAWEI] commit
[~Switch] vlan batch 11
[*Switch] interface eth-trunk 20
[*Switch-Eth-Trunk20] mode lacp-static
[*Switch-Eth-Trunk20] port link-type trunk
[*Switch-Eth-Trunk20] port trunk allow-pass vlan 11
[*Switch-Eth-Trunk20] trunkport 10ge 1/0/1 to 1/0/4
[*Switch-Eth-Trunk20] quit
[*Switch] commit
2. Configure VRRP.
# Configure a VRRP group on SwitchA. The configuration on SwitchB is similar to the
configuration on SwitchA. For details, see its configuration file. The two switches in the
VRRP group work in active-active mode. Configure the same VRID and virtual IP
address on the two switches to provide the same virtual IP address and virtual MAC
address to the M-LAG.
[*SwitchA-Vlanif11] vrrp vrid 1 virtual-ip 10.2.1.111
[*SwitchA] commit
Step 2 Configure OSPF to implement IP interworking.
# Configure SwitchA. The configurations on SwitchB and SwitchC are similar to the
configuration on SwitchA. For details, see their configuration files.
[*SwitchA] ospf 1
[*SwitchA-ospf-1-area-0.0.0.0] quit
[*SwitchA-ospf-1] quit
[*SwitchA] commit
If the peer-link is selected as the optimal link to the RP or multicast source by the unicast routing
protocol, multicast traffic with the peer-link interface as the outbound interface may fail to be forwarded.
To prevent this problem, ensure that the Layer 3 link between the M-LAG master and backup devices
has a route cost smaller than or equal to the route cost of the peer-link, so that the Layer 3 link is
selected as the optimal route by the unicast routing protocol.

Step 3 Enable PIM-SM and IGMP on VLANIF interfaces of SwitchA and SwitchB, and enable PIM-
SM on VLANIF interfaces of SwitchC, so that multicast forwarding entries can be created on
the switches.
# Configure SwitchA. The configuration on SwitchB is similar to the configuration on

SwitchA. For details, see its configuration file.
[*SwitchA-Vlanif11] igmp enable
[*SwitchA] commit
# Configure SwitchC. Configure VLANIF 15 of SwitchC as a C-BSR and C-RP.

[*SwitchC] pim
[*SwitchC-pim] c-bsr vlanif 15
[*SwitchC-pim] c-rp vlanif 15
[*SwitchC-pim] quit
[*SwitchC] commit
Step 4 Enable the PIM silent function on user-side VLANIF interfaces of SwitchA and SwitchB.

[*SwitchA] commit
Step 5 On SwitchA and SwitchB, enable IGMP snooping in the VLANs corresponding to the
VLANIF interfaces.

[~SwitchA] igmp snooping enable
[*SwitchA] vlan 11
[*SwitchA-vlan11] igmp snooping enable
[*SwitchA-vlan11] quit
[*SwitchA] vlan 12
[*SwitchA] vlan 13
[*SwitchA] commit
Step 6 Disable STP on the interfaces at both sides of the Layer 3 link between the M-LAG master
and backup switches, and specify the VLAN that is not allowed on the peer-link.


[~SwitchA] interface 10ge 1/0/6
[~SwitchA-10GE1/0/6] stp disable
[*SwitchA-Eth-Trunk1] port vlan exclude 1 13
[*SwitchA] commit

# Run the display dfs-group command on SwitchA to check M-LAG information.
[~SwitchA] display dfs-group 1 m-lag
* : Local node
Heart beat state : OK
Node 1 *
Dfs-Group ID : 1
Priority : 150
Address : ip address 10.1.1.1
State : Master
Causation : -
System ID : 0025-9e95-7c31
SysName : SwitchA
Version : V200R003C00SPC200
Device Type : CE6850EI
Node 2
Dfs-Group ID : 1
Priority : 120
Address : ip address 10.1.1.2
State : Backup
Causation : -
System ID : 0025-9e95-7c11
SysName : SwitchB
Version : V200R003C00SPC200
Device Type : CE6850EI
The Heart beat state field is OK, indicating that the heartbeat between the two switches is
normal. SwitchA, acting as Node 1, has a priority of 150 and is in Master state. SwitchB,
acting as Node 2, has a priority of 120 and is in Backup state. The preceding information
shows that SwitchA is the M-LAG master device, and SwitchB is the M-LAG backup device.
# Run the display pim interface command on SwitchA and SwitchB to check the PIM
configuration and running status on interfaces.
[~SwitchA] display pim interface
Vlanif11 up 0 30 1 10.2.1.1 (local)
Vlanif12 up 1 30 1 10.3.1.2
Vlanif13 up 1 30 1 10.5.1.2
[~SwitchB] display pim interface
Vlanif11 up 0 30 1 10.2.1.2 (local)
Vlanif14 up 0 30 1 10.4.1.2
Vlanif13 up 0 30 1 10.5.1.2 (local)
According to the preceding information, VLANIF 11 of SwitchA and VLANIF 11 of SwitchB

are both DRs; therefore, both SwitchA and SwitchB will send Join messages to the upstream
RP.
# Run the display pim routing-table command on SwitchA, SwitchB, and SwitchC to check
the PIM-SM routing tables on them.

(*, 225.1.1.1)
RP: 10.6.1.1 (local)
UpTime: 00:14:45
1: Vlanif12
2: Vlanif14
(10.6.1.2, 225.1.1.1)
RP: 10.6.1.1 (local)
UpTime: 00:15:47
1: Vlanif12
2: Vlanif14
According to the preceding information, SwitchC has two downstream interfaces VLANIF 12
and VLANIF 14. Because both SwitchA and SwitchB are DRs, data sent from the multicast
source is forwarded to the two switches through the two downstream interfaces. In real-world
application, the downstream interfaces on SwitchC are determined by the unicast routes from
the DRs to the RP.
(*, 225.1.1.1)
RP: 10.6.1.1
UpTime: 00:18:31
1: Vlanif11
(10.6.1.2, 225.1.1.1)
RP: 10.6.1.1
UpTime: 00:17:31
1: Vlanif11
(*, 225.1.1.1)

RP: 10.6.1.1
UpTime: 00:18:59
1: Vlanif11
(10.6.1.2, 225.1.1.1)
RP: 10.6.1.1
UpTime: 00:17:59
1: Vlanif11
The preceding information shows that both SwitchA and SwitchB have a downstream
interface VLANIF 11. When the M-LAG is functioning normally, both the M-LAG master
and backup member interfaces can forward multicast data traffic to the receiver, implementing
load sharing. The M-LAG master and backup devices share load according to the following
rule: If the last decimal number of the multicast group address is an odd number, such as the
address 225.1.1.1, the M-LAG master member interface forwards the multicast data traffic. If
the last decimal number of the multicast group address is an even number, such as the address
225.1.1.2, the M-LAG backup member interface forwards the multicast data traffic. In this
example, the M-LAG master member interface forwards data traffic to the multicast group
address 225.1.1.1.
----End
Configuration Files
#
sysname SwitchA
#
dfs-group 1
priority 150
source ip 10.1.1.1
#
vlan batch 11 to 13
#
stp mode rstp
stp v-stp enable
#
#
igmp snooping enable
#
vlan 11
#
vlan 12
#
vlan 13
#
interface Vlanif11

ip address 10.2.1.1 255.255.255.0

vrrp vrid 1 virtual-ip 10.2.1.111
pim silent
pim sm
igmp enable
#
interface Vlanif12
ip address 10.3.1.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif13
ip address 10.5.1.1 255.255.255.0
pim sm
igmp enable
#
interface MEth0/0/0
ip address 10.1.1.1 255.255.255.0
#
interface Eth-Trunk1
mode lacp-static
peer-link 1
port vlan exclude 1 13
#
mode lacp-static
dfs-group 1 m-lag 1
lacp m-lag priority 10
lacp m-lag system-id 00e0-fc00-0000
#
interface 10GE1/0/1
#
interface 10GE1/0/2
eth-trunk 10
#
interface 10GE1/0/3
eth-trunk 10
#
interface 10GE1/0/4
eth-trunk 1
#
interface 10GE1/0/5
eth-trunk 1
#
interface 10GE1/0/6
stp disable
#
ospf 1
area 0.0.0.0
network 10.1.1.1 0.0.0.255
network 10.3.1.0 0.0.0.255
network 10.5.1.0 0.0.0.255
#
return
#
sysname SwitchB
#
dfs-group 1
priority 120
source ip 10.1.1.2
#

#
stp mode rstp
stp v-stp enable
#
#
#
vlan 11
#
vlan 13
#
vlan 14
#
interface Vlanif11
ip address 10.2.1.2 255.255.255.0
vrrp vrid 1 virtual-ip 10.2.1.111
pim silent
pim sm
igmp enable
#
interface Vlanif13
ip address 10.5.1.2 255.255.255.0
pim sm
igmp enable
#
interface Vlanif14
ip address 10.4.1.1 255.255.255.0
pim sm
igmp enable
#
interface MEth0/0/0
ip address 10.1.1.2 255.255.255.0
#
mode lacp-static
peer-link 1
port vlan exclude 1 13
#
mode lacp-static
dfs-group 1 m-lag 1
lacp m-lag priority 10
lacp m-lag system-id 00e0-fc00-0000
#
interface 10GE1/0/1
#
interface 10GE1/0/2
eth-trunk 10
#
interface 10GE1/0/3
eth-trunk 10
#
interface 10GE1/0/4
eth-trunk 1
#
interface 10GE1/0/5
eth-trunk 1
#
interface 10GE1/0/6

stp disable
#
ospf 1
area 0.0.0.0
network 10.1.1.2 0.0.0.255
network 10.4.1.0 0.0.0.255
network 10.5.1.0 0.0.0.255
#
return
#
sysname SwitchC
#
#
#
interface Vlanif12
ip address 10.3.1.2 255.255.255.0
pim sm
#
interface Vlanif14
ip address 10.4.1.2 255.255.255.0
pim sm
#
interface Vlanif15
ip address 10.6.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.3.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
network 10.6.1.0 0.0.0.255
#
pim
c-bsr Vlanif15
c-rp Vlanif15
#
return
l Switch configuration file
#
sysname Switch
#
vlan batch 11
#
mode lacp-static
#
interface 10GE1/0/1
eth-trunk 20
#
interface 10GE1/0/2
eth-trunk 20
#

interface 10GE1/0/3
eth-trunk 20
#
interface 10GE1/0/4
eth-trunk 20
#
return
3.14 Troubleshooting IPv4 PIM
3.14.1 SPT on an IPv4 PIM-DM Network Fails to Be Established
Fault Description
After PIM-DM configuration is complete on a network, user hosts use Internet Group
Management Protocol (IGMP) to send requests to group G. However, the user hosts cannot
receive any multicast data.
Procedure
Step 1 Check whether a reachable unicast route to the multicast source is available.
Run the display ip routing-table command to check whether the switch has a unicast route to
the multicast source.
Multicast routing depends on unicast routing. If the switch does not have a unicast route to the
multicast source, configure a unicast routing protocol to dynamically generate a route or
configure a unicast static route to the multicast source.
Step 2 Check whether PIM-DM is enabled on interfaces, especially the reverse path forwarding
(RPF) interface towards the multicast source.
Run the display pim interface command to check PIM information on each interface.
If no PIM information is displayed on an interface or the PIM mode on the interface is sparse,
PIM-DM is not enabled on the interface. Run the pim dm command in the interface view to
enable PIM-DM.
Step 3 Check whether IGMP is enabled on the interface directly connected to the network segment
of the user hosts.
Run the display igmp interface command to check the IGMP configuration on the interface
directly connected to the network segment of the user hosts.
If no information is displayed, IGMP is not enabled on the interface. Run the igmp enable
command in the interface view to enable IGMP.
----End
3.14.2 RPT on an IPv4 PIM-SM Network Fails to Be Established

Fault Symptom
The rendezvous point tree (RPT) used to provide the Any-Source Multicast (ASM) service
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 rendezvous point (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 reverse path forwarding (RPF) route to the RP is incorrect, for example, a unicast
routing loop occurs.
l Configurations are incorrect, for example, the configuration of the maximum
transmission unit (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 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:
n 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.
n If the local device is the RP, the RPT has been established successfully. In this
case, check whether the source's designated router (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,
– 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
3.14.3 SPT on an IPv4 PIM-SM Network Fails to Be Established
Fault Symptom
The shortest path tree (SPT) fails to be established on a network. 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 Configurations (such as the 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 tables 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.
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.
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.
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.
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.14.4 After the Source DR Sends a Register Message to the RP,

the Registration Interface Still Exists in the Corresponding
Multicast Forwarding Entry
Fault Description
On a deployed multicast network, the multicast source sends multicast data to the source
designated router (DR). The source DR encapsulates the multicast data into a Register
message and sends the Register message to the rendezvous point (RP). After the source DR
sends the Register message to the RP, the registration interface still exists in the
corresponding multicast forwarding entry. No SPT is set up between the source DR and RP.
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.
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 shortest path tree (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. In such a case, different PIM protocols may be
configured on interfaces of devices between the RP and source DR.
----End

Configuration Guide - IP Multicast 4 MSDP Configuration
4 MSDP Configuration
This chapter describes how to configure the Multicast Source Discovery Protocol (MSDP) to
implement multicast routing and data forwarding between Protocol Independent Multicast
Sparse Mode (PIM-SM) domains and anycast rendezvous point (RP) in a PIM-SM domain.
"Router" mentioned in this chapter and the router icon used in figures refer to a conventional router or
Layer 3 switch.
4.1 Overview of MSDP

4.2 Understanding MSDP
4.3 Application Scenarios for MSDP
4.4 Summary of MSDP Configuration Tasks
4.5 Licensing Requirements and Limitations for MSDP
4.6 Default Settings for MSDP
4.7 Configuring Basic MSDP Functions
4.8 Controlling SA Messages and the SA Cache
4.9 Configuring MSDP Anycast RP
4.10 Maintaining MSDP
4.11 Configuration Examples for MSDP
4.12 Troubleshooting MSDP
4.1 Overview of MSDP
Definition
Multicast Source Discovery Protocol (MSDP) is an inter-domain multicast solution developed
for interconnection among multiple Protocol Independent Multicast Sparse Mode (PIM-SM)
domains. It is used to discover information about multicast sources in other PIM-SM
domains.

MSDP can be deployed only on an IPv4 network and the intra-domain multicast routing
protocol must be PIM-SM. MSDP is valid only for the Any-Source Multicast (ASM) model.
Purpose
In PIM-SM mode, a source designated router (DR) registers to a rendezvous point (RP) and a
receiver DR sends Join messages to the RP. Therefore, the RP can obtain information about
all multicast sources and group members. With network expansion, administrators divide a
PIM-SM network into multiple PIM-SM domains to facilitate control of multicast resources.
In this case, the RP in a PIM-SM domain cannot obtain multicast source information in other
PIM-SM domains. MSDP is introduced to solve this problem.
MSDP establishes MSDP peers between routers (usually RPs) in different PIM-SM domains
to exchange Source-Active (SA) messages, so that the peers share multicast source
information. MSDP allows multicast users in a PIM-SM domain to receive multicast data
from multicast sources in other domains.
MSDP sets up peer relationships between Internet Service Provider (ISP) networks. In
general, an ISP does not want to rely on other ISPs to provide services to its own users. The
ISP wants to improve the network security and prevent complaints on service interruption
caused by RP faults of other ISPs' networks. MSDP allows ISPs to exchange multicast data
with the Internet using RPs.
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 relationships are 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.
Benefits
MSDP implements inter-domain multicast and provides the following advantages for ISPs:
l A PIM-SM domain provides services using the local RPs, decreasing the dependency on
RPs in other PIM-SM domains. MSDP controls whether source information in a domain
is transmitted to another domain, improving network security.
l If there are only receivers in a domain, the receivers can receive multicast data when
they report the group memberships in the local PIM-SM domain but not on the entire
network.
l Devices in a PIM-SM domain do not need to maintain multicast source information and
routing entries on the entire network, saving system resources.
4.2 Understanding MSDP
4.2.1 MSDP Peers

The first task for implementing inter-domain multicast is to establish MSDP peer
relationships.
RPs in PIM-SM domains set up MSDP peer relationships. MSDP peers exchange SA
messages that carry (S, G) information generated when source DRs register to the RPs.

Message exchange among MSDP peers ensures that SA messages sent by any RP can be
received by all the other RPs.
As shown in Figure 4-1, MSDP can be deployed on other PIM routers apart from the RPs.
MSDP peers established on different PIM routers have different functions.
Figure 4-1 Locations of MSDP peers
PIM-SM1 RouterB
PIM-SM2
RouterA
Source
RP1 RP2
PIM-SM3
Receiver RP3
MSDP peers
l Establish MSDP peers on RPs.

Classificatio Location Function
n
MSDP peer Closest to the The source RP creates SA messages, sends

on the source multicast source SA messages to remote MSDP peers, and
end (generally the source advertises multicast source information
RP, such as RP1) registered to the local RP.
The MSDP peer on the source end must be
configured on an RP. Otherwise, the MSDP
peer on the source end cannot advertise
multicast source information.

Classificatio Location Function

n
MSDP peer Closest to the receiver After receiving SA messages, the MSDP
on the (such as RP3) peer on the receiver end joins an SPT with
receiver end the multicast source being the root
according to source information contained
in SA messages. After receiving multicast
data from this source, the peer forwards
multicast data along the rendezvous point
tree (RPT) to local receivers.
The MSDP peer on the receiver end must
be configured on an RP. Otherwise, the
MSDP peer on the receiver end cannot
receive multicast source information from
other domains.
Intermediate Having multiple The intermediate MSDP peer forwards SA

MSDP peer remote MSDP peers messages received from a remote MSDP
(such as RP2) peer to other remote MSDP peers.
l Establish MSDP peers on common PIM routers but not the RPs.
These MSDP peers (such as RouterA and RouterB) only forward SA messages they
receive.
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.
4.2.2 MSDP Packets
MSDP packets are encapsulated in TCP packets and are in the format of Type Length Value
(TLV), as shown in Figure 4-2.
Figure 4-2 Format of MSDP packets

TCP segment
IP header TCP header
(TLV)
Type Length Value
8 bits 16 bits Variable length
l Type: indicates the packet type. Table 4-1 lists types of MSDP packets.

l Length: indicates the packet length.

l Value: indicates the packet content that depends on the packet type.
Table 4-1 Types of MSDP packets

Value MSDP Packet Function Major Information
Type Contained
1 Source-Active Carries multiple l IP address of the source RP.

(SA) groups of (S, G) l Number of (S, G) entries
entries and is contained in an SA message.
transmitted among
several RPs. l List of active (S, G) entries
in the domain.
Encapsulates PIM-SM l IP address of the source RP.

multicast data. l PIM-SM multicast data.
2 Source-Active Actively requests (S, Address of the group G.

Request G) list of a specified
(SA-Req) group G to reduce the
delay for joining the
group.
3 Source-Active Responds to SA l IP address of the source RP.

Response request messages. l Number of (S, G) entries
(SA-Resp) contained in an SA-Resp
message.
l List of active (S, G) entries
in the domain.
4 KeepAlive Maintains MSDP peer -

connections. The
Keepalive packet is
sent only when no
other protocol packet
is exchanged between
MSDP peers.
5 Reserved This packet type is -

reserved and used as
Notification messages
at present.
6 Traceroute in Traces and detects the l IP address of the source RP.

Progress RPF path along which l List of active (S, G) entries
SA messages are in the domain.
7 Traceroute Reply transmitted.
l Search ID
l Returned search information
l Number of hops

As described in Table 4-1, SA messages carry (S, G) information and encapsulate multicast
packets. MSDP peers share (S, G) information by exchanging SA messages. 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.
When a new user joins the group, the user must wait for the SA message sent by the MSDP
peer in the next period because SA messages are sent periodically. To reduce the delay for the
new user to join the source SPT, MSDP supports SA request and response messages of Type 2
and Type 3 to improve the update efficiency of active source information.
4.2.3 Process of Setting Up MSDP Peer Relationships
Setting Up MSDP Peer Relationships

MSDP peers use port 639 to set up TCP connections.
After MSDP is enabled on two devices and they are specified as MSDP peers to each other,
the devices compare their IP addresses. The device with the smaller IP address starts the
ConnectRetry timer and initiates a TCP connection to the other device. The device with the
larger IP address monitors whether a TCP connection is set up on the port 639. The MSDP
peer relationship is set up after a TCP connection is set up. MSDP peers maintain the TCP
connection by exchanging Keepalive messages.
Figure 4-3 Process of setting up an MSDP peer relationship
RouterA RouterB
10.1.1.1/24 10.1.1.2/24
Down Down
1. Enable MSDP peer
2.a. TCP active open,

set ConnectRerty timer
Connect
Listen
2.b. TCP passive open
3. TCP established
Up active side passive side Up
4. KeepAlive message

As shown in Figure 4-3, an MSDP peer relationship is set up between RouterA and RouterB
in a process as follows:
1. In initial state, the MSDP session status of the two routers is Down.
2. After MSDP is enabled and they are specified as MSDP peers to each other, the routers
compare their IP addresses used to set up a TCP connection.
– RouterA has a smaller IP address. Therefore, it enters the Connect state, initiates a
TCP connection to RouterB, and starts the ConnectRetry timer. This timer
determines the interval for retrying setting up the TCP connection.
– RouterB has a larger IP address. Therefore, it enters the Listen state and waits for a
connection initiated by the peer.
3. After a TCP connection is set up, the MSDP session status of the two ends become Up.
4. MSDP peers send Keepalive messages to each other to request the peer to maintain the
MSDP connection status.
MSDP Authentication
To improve MSDP security, MSDP peers perform TCP connection authentication. You must
configure the same encryption algorithm and password on the two ends of an MSDP peer
relationship. Otherwise, the TCP connection cannot be set up between MSDP peers. MSDP
supports two encryption modes: MD5 and Keychain. The two modes are mutually exclusive,
and you can configure only one of them between MSDP peers.
4.2.4 Inter-domain Multicast Source Information Transmission

Among Domains
As shown in Figure 4-4, the PIM-SM network is divided into four PIM-SM domains. There is
an active multicast source (Source) in the domain PIM-SM1, and RP1 knows the existence of
this source after the source registers to RP1. Domains PIM-SM2 and PIM-SM3 want to know
the exact position of this source to receive multicast data from it. MSDP peer relationships
must be set up between RP1 and RP2, and between RP2 and RP3.

Figure 4-4 Inter-domain multicast source information transmission

Receiver
PIM-SM3
DR3 RP3
Source DR1
PIM-SM4
PIM-SM1
RP2
RP1 PIM-SM2
MSDP peers
multicast packet
Register message
SA message
Join message
Multicast source information is transmitted among domains under the following process:
1. When Source in PIM-SM1 sends the first multicast packet to the multicast group, the
designated router DR1 encapsulates multicast data to a register message and sends the
message to RP1. RP1 then obtains information about this multicast source.
2. As a source RP, RP1 creates SA messages and periodically sends SA messages to its
peer RP2. SA messages contain the multicast source address S, the group address G, and
the address of the source RP1 that creates the SA message.
3. After receiving SA messages, RP2 performs a reverse path forwarding (RPF) check. RP2
forwards messages that pass the RPF check to RP3, and checks whether there is a
member of group G in the local domain. Because PIM-SM2 contains no receiver of
group G, RP2 does not perform any other action.
4. After RP3 receives the SA message, it performs an RPF check on the message. The
check succeeds. Because a member of group G locates in PIM-SM3, RP3 generates a (*,
G) entry using IGMP.
5. RP3 creates an (S, G) entry and sends a Join message with (S, G) information to Source
hop by hop. A multicast path (the shortest path tree SPT) from Source to RP3 is then set
up. After multicast data reaches RP3 along the SPT, RP3 forwards the data to the
receiver along the RPT.
6. After the receiver DR3 receives multicast data from Source, it determines whether to
initiate an SPT switchover.

4.2.5 Controlling the Forwarding of SA Messages

To control SA message transmission among MSDP peers and prevent loops, configure rules
for filtering SA messages. After the rules are configured, the device receives and forwards
only SA messages that are transmitted along a correct path and match the rules. In addition,
you can configure an MSDP mesh group for the MSPD peers to prevent them from flooding
SA messages.
RPF Rules of SA Messages

To prevent SA messages from being circularly forwarded among MSDP peers, MSDP
performs the RPF check on received SA messages. MSDP strictly controls the incoming SA
messages, and discards the SA messages that do not comply with the RPF rules.
After receiving SA messages, the MSDP-enabled device determines the RPF peer of the
source RP based on Multicast RPF Routing Information Base (MRIB). The RPF peer is the
next hop along the optimal path from the RP that creates SA messages. If an SA message is
sent by an RPF peer, the message is accepted and forwarded to other MSDP peers. MRIB
includes MBGP, multicast static route, and BGP and IGP unicast routing.
Apart from the rule mentioned above, the device complies with the following rules when
forwarding SA messages:
l Rule 1: If the peer that sends the SA message is the source RP, the SA message is
accepted and forwarded to other peers.
l Rule 2: If the peer that sends the SA message is a static RPF peer, the SA message is
accepted. One router can set up MSDP peer relationships with multiple routers
simultaneously. You can select one or more peers from these remote peers as a static RPF
peer or RPF peers.
l Rule 3: If a router has only one remote MSDP peer, the remote peer automatically
becomes the RPF peer. The router accepts the SA message sent by this remote peer.
l Rule 4: If a peer and the local router are in the same mesh group, the SA message sent by
this peer is accepted. The SA message is not forwarded to members of this mesh group
but all the other peers outside the mesh group.
l Rule 5: If the route that reaches the source RP spans multiple ASs, only the SA message
sent by a peer in the next hop AS is accepted. If this AS has multiple remote MSDP
peers, the SA message sent by the peer with the largest IP address is accepted.
l Rule 6: If an SA message is sent from an MSDP peer that is a route advertiser or the next
hop of a source RP, the receiving router permits the SA message. If a network has
multiple equal-cost routes to a source RP, the router permits SA messages sent from all
MSDP peers on the equal-cost routes.
The application of rules 5 and 6 depends on route types.
l If a route to a source RP is a BGP or an MBGP route:
– If an MSDP peer is an EBGP or MEBGP peer, rule 5 applies.
– If an MSDP peer is an IBGP or MIBGP peer, rule 6 applies.
– If an MSDP peer is not a BGP or an MBGP peer and the route to the source RP is
an inter-AS route, rule 5 applies. Rule 6 applies in other cases.
l If a route to a source RP is not a BGP or an MBGP route:
– If IGP or multicast static routes exist, rule 6 applies.

– If no routes exist, the router discards SA messages sent from MSDP peers.
MSDP Mesh Group

When there are multiple MSDP peers on a network, SA messages are flooded among these
MSDP peers. The MSDP peer needs to perform the RPF check on each received SA message,
causing a heavy burden to the system. Configuring multiple MSDP peers to join the same
mesh group can reduce the number of SA messages transmitted among these MSDP peers.
Mesh group members can be located in one or more PIM-SM domains. They can also be
located in the same AS or multiple ASs.
You must set up MSDP peer relationships between any two members of the mesh group and
the two members must identify each other as the member of the same mesh group. As shown
in Figure 4-5, RouterA, RouterB, RouterC, and RouterD belong to the same mesh group. On
each router, you must set up MSDP peer relationships with the other three routers.
Figure 4-5 Networking diagram of MSDP peer relationships among mesh group members
RouterA
Mesh group
RouterD RouterB
RouterC
MSDP peers
After mesh group members receive SA messages, they check the source of these SA
messages.
l If the SA message is sent by a certain MSDP peer outside the mesh group, the member
performs the RPF check on the SA message. If the message passes the RPF check, the
member forwards this message to all the other members in the mesh group.
l If the SA message is sent by a member of the mesh group, the member directly accepts
the message without performing the RPF check. In addition, it does not forward the
message to other members in the mesh group.
Filtering SA Messages
By default, MSDP does not filter SA messages. SA messages sent from a domain are
transmitted to all MSDP peers on the network.
However, (S, G) entries in some PIM-SM domains guide the forwarding within local PIM-SM
domains. For example, some local multicast applications use global multicast group addresses
or some multicast sources use private addresses 10.x.x.x. If SA messages are not filtered,
these (S, G) entries are transmitted to other MSDP peers. To address this problem, configure

rules (ACL rules are often used) for filtering SA messages, and apply these rules when
creating, forwarding, or receiving SA messages.
4.3 Application Scenarios for MSDP
4.3.1 Multicast Between PIM-SM Domains Within an AS Using

MSDP
When the multicast source and the receiver are located in different PIM-SM domains of the
same AS, you can configure MSDP peers on the RPs to implement inter-domain multicast.
Figure 4-6 PIM-SM inter-domain multicast in an AS
AS 100
Source Receiver
PIM-SM2
PIM-SM1
RP1 RP2
RouterA RouterB
MSDP peers
As shown in Figure 4-6, the MSDP peer relationship is set up between RPs of two PIM-SM
domains. In this manner, information about the multicast source is shared between the two
domains.
4.3.2 Inter-AS Multicast Using MBGP and MSDP
Both Multiprotocol Border Gateway Protocol (MBGP) connections and MSDP connections
are TCP connections. You can set up an MBGP peer relationship between two MSDP peers to
ensure that SA messages can pass the RPF check.

Figure 4-7 Inter-AS multicast using MBGP and MSDP
AS 100
Source1 Receiver2
PIM-SM1
RP1 PIM-SM2 RP2
ASBR1 ASBR2
AS 200
ASBR3 ASBR4
PIM-SM3
RP3 RP4
Receiver3
Source3
MSDP peers
MBGP peers
As shown in Figure 4-7, the RPs in different PIM-SM domains are not directly connected to
each other and the RPs and ASBRs are deployed on different routers. After you set up MSDP
peer relationships between the RPs, you can also set up MBGP peer relationships between
them to ensure that SA messages can pass the RPF check.
l IBGP: set up IBGP peer relationships for RPs in the same AS, such as RP1 and RP2, and
RP3 and RP4.
l EBGP: set up EBGP peer relationships for RPs in different ASs, such as RP1 and RP3,
and RP2 and RP4.

The MBGP peer relationship and MSDP peer relationship must be set up on the same
interface. MBGP and MSDP are frequently used together. For details about MBGP, see
"BGP" in the CloudEngine 6800 Series Switches Configuration Guide- IP Routing.
4.3.3 Inter-AS Multicast Using Static RPF Peers

As mentioned in RPF Rules of SA Messages, if an SA message is sent by an RPF peer, the
message is accepted and forwarded to other MSDP peers. If you manually specify MSDP
peers as static RPF peers to one another, these RPF peers accept SA messages without
performing the RPF check.
Incorrect static RPF configurations may lead to loops of SA messages. Exercise caution when
you configure static RPF peers. Static RPF peer relationships are usually set up among MSDP
peers in multiple ASs.
Figure 4-8 Inter-AS multicast using static RPF peers
AS 100 AS 200
Source
Receiver
PIM-SM1
PIM-SM2
RP1
RP2
ASBR1 ASBR2
MSDP peers
Static RPF peers
The configuration plan is as follows:

1. Configure an MSDP peer relationship between RP1 and RP2.
2. Configure RP1 and RP2 as static RPF peers of each other.
4.3.4 MSDP-based Anycast RP

MSDP peer relationships are set up between RPs to exchange SA messages, so that source
information registered locally can be shared by the RPs. Anycast RP is the application of this
feature in one PIM-SM domain.
In a traditional PIM-SM domain, all multicast groups map to one RP. When the network is
overloaded or the traffic volume is high, many network problems occur, such as the heavy

pressure of the RP, the slow convergence after the RP fails, and the non-optimal multicast
forwarding path. By using Anycast RP, you can configure multiple RPs in a PIM-SM domain,
assign the same IP address to these RPs, and set up MSDP peer relationships between these
RPs. In this manner, the optimal RP path and load balancing can be implemented.
As shown in Figure 4-9, in the PIM-SM domain, the multicast sources, Source1 and Source2,
send multicast data to the multicast group G. Receiver1 and Receiver2 are members of group
G.
Figure 4-9 Networking diagram of Anycast RP
Receiver2
PIM-SM
Source1 Loopback1 RouterB
RP
Source2
Loopback1
BSR
RouterA
RP Receiver1
MSDP peers
Do as follows to apply Anycast RP in a PIM-SM domain:
1. Select several routers in the PIM-SM domain, such as RouterA and RouterB in Figure
4-9.
2. Choose one loopback interface from each router, such as Loopback1 in Figure 4-9, and
assign the same address to these interfaces.
3. Configure the RP. You can configure static RPs or C-RPs, as shown in Figure 4-9.
– Static RP: Configure static RPs on all PIM-SM routers, and use the address of the
interface Loopback1 on RouterA as the address of the RPs.
– C-RP: Configure the two Loopback1 interfaces on RouterA and RouterB as C-RPs.
Configure a C-BSR on the network. Ensure that the address of the C-RP must be
different from the address of the C-BSR.
4. Set up an MSDP peer relationship between RouterA and RouterB. Do not use the
interface addresses of the RPs.

Anycast RP provides the following functions:

l Optimal path between the RPs: The multicast source registers to the closest RP to set up
an optimal SPT. The receiver sends Join messages to the closest RP to set up an optimal
RPT.
l Load balancing between the RPs: Each RP needs to maintain only some source and
group information in the PIM-SM domain, and forward some multicast packets.
l RP backup: When an RP fails, the multicast source and receiver registered to this RP
choose another closest RP to register and join.
4.4 Summary of MSDP Configuration Tasks

Table 4-2 lists MSDP configuration tasks.
Table 4-2 MSDP configuration tasks

Task Description
4.7 Configuring Basic MSDP Functions When a PIM-SM network is divided into
multiple PIM-SM domains, configure basic
MSDP functions on the multicast switch to
allow the RP in each domain to learn
information about multicast sources in other
domains and members in each domain to
receive multicast data from multicast
sources in other domains.
4.8 Controlling SA Messages and the SA MSDP peers share (S, G) information by
Cache exchanging SA messages. To control SA
messages in actual applications, configure
the control over SA messages and the SA
cache.
4.9 Configuring MSDP Anycast RP MSDP anycast RP allows multicast sources

to register with the closest RP and allows
receivers to join the closest RP. This
releases burdens on a single RP, implements
RP backup, and optimizes the forwarding
path.
4.5 Licensing Requirements and Limitations for MSDP

a multicast source.

MSDP is a basic software function of the switch. The license for basic software functions has
been loaded and activated before delivery. You do not need to manually activate it.

Required
CE5810EI V100R002C00
CE5850EI V100R001C00
CE5850HI V100R003C00
CE5855EI V100R006C00
CE5880EI V200R005C10
CE6810EI V100R003C00
CE6850EI V100R001C00
CE6850-48S6Q-HI V100R005C00
CE6855HI V200R001C00
CE6856HI V200R002C50
CE6857EI V200R005C10


Required
CE6860EI V200R002C50
CE6865EI V200R005C00
CE6870-48T6CQ-EI V200R002C50
CE6875EI V200R003C00
CE6880EI V200R002C50
CE6881/CE6820/CE6863 V200R005C20
CE7850EI V100R003C00
CE7855EI V200R001C00
CE8850-32CQ-EI V200R002C50
CE8850-64CQ-EI V200R005C00
CE8860EI V100R006C00
CE8861EI/CE8868EI V200R005C10
Feature Limitations
1000 to 2000 1000 seconds
2000 to 8000 2000 seconds
following points:

other services
Item Precautions
deployed with
M-LAG In V100R006C00 and later versions, an M-LAG set up with


4.6 Default Settings for MSDP

Table 4-5 lists the default settings for MSDP.
Table 4-5 Default settings for MSDP
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.7 Configuring Basic MSDP Functions
Context
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, configure the multicast function in each
Protocol Independent Multicast Sparse Mode (PIM-SM) domain.
4.7.1 Enabling MSDP and 4.7.2 Configuring MSDP Peers are mandatory and other tasks
are optional.
4.7.1 Enabling MSDP

Context
To enable all rendezvous points (RPs) on a network to share source information and to
minimize the number of MSDP—enabled devices, 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 2 Run msdp [ vpn-instance vpn-instance-name ]
MSDP is enabled and the MSDP view is displayed.
Step 3 Run commit
----End
4.7.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
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.
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.

Step 5 (Optional) Run timer retry interval

The interval at which MSDP peers retry to set up a connection with each other is set.
By default, the interval for retrying to set up an MSDP peer relationship is 30 seconds. 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) Run peer peer-address hold-time-interval holdtime-value
The holdtime timer value for the entry of an MSDP peer relationship is set.
By default, the holdtime timer value for the entry of an MSDP peer relationship is 90s. After
an MSDP peer relationship is established, an MSDP peer entry is created, and a holdtime
timer is started for the entry. The holdtime timer is reset each time a message is received from
the MSDP peer and deleted when the relationship is torn down.
Step 7 (Optional) Run peer peer-address keepalive-interval keepalive-time-value
The keepalive timer value for an MSDP peer is set.
By default, the keepalive timer value for an MSDP peer is 60s. After an MSDP peer
relationship is established, both ends send keepalive messages, and a keepalive timer is started
for the MSDP peer. The keepalive timer is reset each time the local end sends a keepalive
message upon timer expiration and deleted when the relationship is torn down. The keepalive
timer value set on the local end must be less than the holdtime timer value set by the peer
hold-time-interval command on the peer end for the corresponding MSDP peer relationship
entry.
Step 8 (Optional) Configure an MSDP authentication mode.
To improve the security of a TCP connection, MSDP supports two authentication modes:
message digest algorithm 5 (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.
MD5 is not a secure authentication algorithm. For security purposes, you are advised to use the more
secure Keychain algorithm for MSDP authentication.
l Run peer peer-address password { cipher cipher-password | simple simple-password }
MSDP MD5 authentication is configured.

NOTICE
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 Series Switches Configuration
Guide-Security.
Step 9 (Optional) Run 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-address command to set up a session with the remote MSDP peer and to
reestablish a TCP connection.
Step 10 Run commit
----End
4.7.3 (Optional) Configuring Static RPF Peers
Prerequisites
MSDP peers have been configured. For details, see 4.7.2 Configuring MSDP Peers.
Context
The device does not perform reverse path forwarding (RPF) checks on SA messages received
from static RPF peers. Therefore, Source-Active (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 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
----End
4.7.4 (Optional) Configuring the MSDP Mesh Group
Prerequisites
MSDP peers have been configured. For details, see 4.7.2 Configuring MSDP Peers.
Context
An autonomous system (AS) may contain multiple MSDP peers. To prevent these MSDP
peers from flooding Source-Active (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 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 commit
----End
4.7.5 Verifying the Basic MSDP Function Configuration
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 [ vpn-instance vpn-instance-name | all-instance ] brief
command to check brief information about MSDP peers.
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] peer-status
[ peer-address ] command to check the detailed information about MSDP peers.
----End
4.8 Controlling SA Messages and the SA Cache
Context
MSDP peers share (S, G) information by exchanging Source-Active (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.7 Configuring Basic MSDP
Functions.
The following configuration tasks can be performed at any sequence as required.

4.8.1 Configuring the SA Cache
Context
To shorten the delay of obtaining multicast information, enable the Source-Active (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 the local cache for the (*,
G) entry carried in the message:
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.
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 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.
Step 4 (Optional) Run peer peer-address sa-cache-maximum sa-limit
The maximum number of (S, G) entries is set.
By default, a maximum of 8192 (S, G) entries can be saved to the SA cache.
Step 5 Run commit
----End
4.8.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 Source-Active (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.
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 3 Configure a local rendezvous point (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 [ basic-acl-number | acl-name acl-name ]
A rule for filtering received SA Request messages is configured.
Step 5 Run commit
----End
4.8.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 designated router (DR) can only encapsulate
multicast data into Register messages, and send the messages to the source rendezvous point
(RP). The source RP transmits (S, G) information contained in Source-Active (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
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 3 Run encap-data-enable
The function of encapsulating multicast data packets in SA messages is enabled.
Step 4 (Optional) Run 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.8.4 Configuring the Rule for Filtering SA Messages
Context
By default, a device receives all Source-Active (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.

Procedure
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 } [ advanced-acl-number | acl-name acl-
name ]
The rules for filtering the received SA messages or the SA messages to be forwarded are set.
Step 5 Run commit
----End
4.8.5 Verifying the Configuration of Parameters for SA Messages

and SA Caching
Context
After configuring parameters for Source-Active (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 [ vpn-instance vpn-instance-name | all-instance ] sa-cache
[ group-address | source-address | as-number ] * command to check (S, G) information in
the SA cache.
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] sa-count [ as-
number ] command to check the number of (S, G) entries in the SA cache.
----End
4.9 Configuring MSDP Anycast RP
Context
Anycast rendezvous point (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.

Enable Protocol Independent Multicast Sparse Mode (PIM-SM) function on all switches in
the PIM-SM domain, without configuring RP.
Perform configuration tasks in the listed sequence.
4.9.1 Configuring an RP
Context
In the anycast rendezvous point (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 candidate
rendezvous points (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 dynamic RP, you only need to configure the dynamic RP on the switch
as the anycast RP.
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 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 dynamic RP) Run pim sm
PIM-SM is enabled on the RP interface.
Before configuring a dynamic RP, run this command. This command is not required if you
configure a static RP.
Step 5 Run quit

Step 7 Configure the loopback interface address as a static RP address or a C-RP address.
Run static-rp rp-address
The loopback interface address is configured as a static RP address.
When configuring dynamic RP, configure candidate bootstrap routers (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.9.2 Configuring MSDP Peer Connections
Context
MSDP peer relationships need be set up between rendezvous points (RPs). If there are more
than three switches, ensure every switch has established an MSDP peer relationship with
another switch and every pair of switches have been added to the same mesh group.
The purpose of this task is to set up MSDP peer relationships among multiple RPs. For
details, see 4.7 Configuring Basic MSDP Functions.
4.9.3 Configuring the Source RP Address of the SA Message
Context
In the anycast RP application, you need to configure rendezvous points (RPs) on two or more
devices in a Protocol Independent Multicast Sparse Mode (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 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
4.9.4 Verifying the MSDP Anycast RP Configuration
Context
After configuring anycast rendezvous point (RP) in a Protocol Independent Multicast Sparse
Mode (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 [ vpn-instance vpn-instance-name | all-instance ] brief
command to check brief information about MSDP peers.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] routing-table
command to check RP information about PIM routing entries.
----End
4.10 Maintaining MSDP
4.10.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.
NOTICE
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 [ vpn-instance vpn-instance-name | all-instance ] 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 [ vpn-instance vpn-instance-name | all-instance ] 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 [ vpn-instance vpn-instance-name | all-instance ] 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.10.2 Clearing (S, G) Information in the SA Cache
Context
NOTICE
The (S, G) information in the Source-Active (SA) cache cannot be restored after you clear it.
Therefore, exercise caution when you run the command.
Procedure
l Run the reset msdp [ vpn-instance vpn-instance-name | all-instance ] sa-cache [ group-
address ] command in the user view to clear the (S, G) information in the SA cache.
----End
4.10.3 Monitoring the MSDP Running Status
Context
During the routine maintenance, you can run the following commands in any view to learn the
MSDP running status.
Procedure
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] brief [ state
{ connect | down | listen | shutdown | up } ] command to check brief information about
MSDP peers.
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] sa-cache
[ group-address | source-address | as-number ] * command to check (S, G) information in
the SA cache.
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] sa-count [ as-
number ] command to check the number of (S, G) entries in the SA cache.

l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] 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
4.11 Configuration Examples for MSDP

4.11.1 Example for Configuring PIM-SM Inter-domain Multicast

Using MSDP
As shown in Figure 4-10, two autonomous systems (ASs) exist on the network. Each AS
contains at least one Protocol Independent Multicast Sparse Mode (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.

Figure 4-10 Network diagram of PIM-SM inter-domain multicast
AS200
PIM-SM2
Receiver
AS100
10.110.2.1/24
VLANIF102
10GE1/0/1
10.2.2.2/32
Loopback0
4
8.3.2/2
192.16 300
PIM-SM1 SwitchC VLANIF /2
/0
4 10GE1
/ 2
10.1.1.1/32 .2.2 0
SwitchA
Loopback0
9 2 .168 NIF200/1 /0/2
10GE1IF300 SwitchD
1 VLA E1/ N
0 G V LA .1/24
192.168.1.1/24
1 / 0 /1 1 1 9 2.168.3
VLANIF100 E
10GE1/0/2 10G 200
L A NIF 2.1/24
V 68. 10GE1/0/3
10GE1/0/2 .1
VLANIF100 192 VLANIF400
10.
VLA 0.1.1/
10G F101
192.168.1.2/24 192.168.4.1/24
192.168.4.2/24
11
NI
VLANIF400
E1/
SwitchB
10GE1/0/3
0/1
192.168.5.2/24 SwitchF
24
VLANIF500
10GE1/0/2
10GE1/0/2
S1 SwitchE VLANIF500
192.168.5.1/24 10GE1/0/1
VLANIF103
Loopback0 10.110.3.1/24
10.3.3.3/32
S3
PIM-SM3
MSDP peers
Configure MSDP, and set up MSDP peer relationships between rendezvous points (RPs) in
PIM-SM domains to implement inter-domain multicast.
1. Configure IP addresses for the interfaces on each switch. Configure Open Shortest Path
First (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 candidate bootstrap routers (C-BSRs) and candidate rendezvous points (C-
RPs). Configure the RPs in PIM-SM1 and PIM-SM2 on the ASBRs.
5. Set up MSDP peer relationships between RPs in PIM-SM domains. According to the
reverse path forwarding (RPF) policy, switches receive SA messages from the next hop
destined for the source RP.

Procedure
# According to Figure 4-10, 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 10.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 10.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-Vlanif200] pim sm
# Configure a BSR boundary on VLANIF200 of SwitchB.

[~SwitchB-Vlanif200] pim bsr-boundary
# 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 10.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 : 10.1.1.1
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Total number of dynamic peers : 0
Peer V AS MsgRcvd MsgSent OutQ Up/Down State

PrefRcv
192.168.2.2 4 200 24 21 0 00:13:09
Established 6
[~SwitchC] display bgp peer

BGP local router ID : 10.2.2.2
Local AS number : 200
Total number of peers : 1

Peers in established state : 1

Total number of dynamic peers : 0
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 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

net
---------------------------------------------------------------------------------

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 ?(unknown) 13 0
[~SwitchE] display msdp brief

net
---------------------------------------------------------------------------------

1 1 0 0 0 0
---------------------------------------------------------------------------------

192.168.4.1 Up 00:15:32 ?(unknown) 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
Up/down time: 00:15:47
Resets: 0
Connection interface: Vlanif200 (192.168.2.1)
Number of sent/received messages: 46/46
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: 20/30
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: 10.1.1.1(local)
Protocol: pim-sm, Flag: SPT EXT ACT
UpTime: 00:00:42
1: Vlanif200

Total 1 (*, G) entry; 2 (S, G) entries
(*, 225.1.1.1)
RP: 10.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: 10.2.2.2
Protocol: pim-sm, Flag: SPT MSDP ACT
UpTime: 00:00:42
1: Vlanif300
(10.110.3.2, 225.1.1.1)
RP: 10.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 10.1.1.1 255.255.255.255
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2


#
bgp 100
router-id 10.1.1.1
peer 192.168.2.2 as-number 200
#
ipv4-family unicast
import-route ospf 1
peer 192.168.2.2 enable
#
ospf 1
import-route bgp
area 0.0.0.0
network 10.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
#
#
#
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 10.2.2.2 255.255.255.255
pim sm
#
bgp 200
router-id 10.2.2.2
#
ipv4-family unicast
import-route ospf 1

#
ospf 1
import-route bgp
area 0.0.0.0
network 10.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
#
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 10.3.3.3 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.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.11.2 Example for Configuring Inter-AS Multicast Using Static

RPF Peers
As shown in Figure 4-11, two autonomous systems (ASs) exist on the network. Each AS
contains at least one Protocol Independent Multicast Sparse Mode (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-11 Network diagram of inter-AS multicast using static RPF peers
AS200
PIM-SM2
AS100
10.2.2.2/32
SwitchE Loopback0
192.168.3.1/24 SwitchD
PIM-SM1 VLANIF300
10GE1/0/1
24
. 2 .1/ 00 10GE1/0/1
10.1.1.1/32 68 IF2 /2 VLANIF300
Loopback0 2.1 N /0 10GE1/0/3 192.168.3.2/24
192.16 19 VLA GE1 VLANIF102
8 10
VLANIF.1.1/24 10.110.2.1/24
10GE1 100 SwitchB
/0/1 /2
E 1/0 00 4
G IF2 /2 Receiver
SwitchC 10GE1
VLANIF /0/1 10LAN 8.2.2
V .16
10 A 68
192.16 10 Receiver
VL2.1
8.1.2/20 2
19
G NIF .4.
19
E1 4 1/
4
/0 00 24
192.168.4.2/24
/2
VLANIF400 10.3.3.3/32
10GE1/0/2 Loopback0 10.110.4.1/24
10GE1 192.168.6.1/24 VLANIF104
/0/1 10GE1/0/3
10GE1/0/3 VLAN VLANIF600
S1 VLANIF101
10.110.1.1/24 192.16IF500 10GE1
10GE1/0/2
8.5.2/2 /0/1
4 VLAN 10GE1/0/2 SwitchG
SwitchA 192.16 IF500
8.5.1/2 VLANIF600
4 192.168.6.2/24 10GE1/0/1
SwitchF VLANIF103
10.110.3.1/24
PIM-SM3
S2
BGP peers
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 Open Shortest Path
First (OSPF) in the ASs, configure External Border Gateway Protocol (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 Internet
Group Management Protocol (IGMP) on interfaces connected to network segments of
receiver hosts. Configure Loopback0 interfaces, candidate bootstrap routers (C-BSRs) ,
and candidate rendezvous points (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.
3. Set up MSDP peer relationships between RPs in PIM-SM 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-11, 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-Vlanif400] 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 10.1.1.1 255.255.255.255
[*SwitchC-LoopBack0] commit
[~SwitchC-LoopBack0] quit
[~SwitchC] pim
[~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.
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:
MSDP Peer Brief Information of VPN instance: public net
---------------------------------------------------------------------------------
2 2 0 0 0 0
---------------------------------------------------------------------------------
192.168.3.2 Up 01:07:08 200 8 0
192.168.5.1 Up 00:16:39 200 13 0
[~SwitchD] display msdp brief

---------------------------------------------------------------------------------
1 1 0 0 0 0
---------------------------------------------------------------------------------
192.168.1.1 Up 01:07:09 100 8 0
[~SwitchF] display msdp brief

---------------------------------------------------------------------------------
1 1 0 0 0 0
---------------------------------------------------------------------------------
192.168.4.1 Up 00:16:40 100 13 0
----End

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 10.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
#
interface 10GE1/0/1


#
interface 10GE1/0/2
#
bgp 100
router-id 10.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 10.1.1.1 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.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
peer 192.168.3.2 connect-interface vlanif100
static-rpf-peer 192.168.3.2 rp-policy list-df
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 10.2.2.2 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.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

#
interface 10GE1/0/3
#
bgp 200
router-id 10.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 10.3.3.3 255.255.255.255
pim sm
#
bgp 200
router-id 10.3.3.3
#
ipv4-family unicast
import-route ospf 1
#
ospf 1
import-route bgp
area 0.0.0.0
network 10.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
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 SwitchG configuration file

#
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.11.3 Example for Configuring Anycast RP Using MSDP
As shown in Network diagram of Anycast RP, a Protocol Independent Multicast Sparse
Mode (PIM-SM) domain contains multiple multicast sources and receivers. Rendezvous
points (RPs) in a PIM-SM domain need to be configured as MSDP peers to perform load
balancing.

Figure 4-12 Network diagram of Anycast RP
PIM-SM
User2 SwitchB
10GE1/0/2
10 LA E1
VLANIF102
V 0G
.11 NI /0/
S1
1
10.110.2.2/24
0. F10 1
6. 6
1/
10.110.3.1/24 10.1.1.1/32
24
10.110.5.1/24 VLANIF103 Loopback10 10.110.2.1/24
VLANIF105 10GE1/0/3 VLANIF102
10GE1/0/2 S2
10GE1/0/1
Loopback1
10.4.4.4/32 SwitchD
SwitchA
10GE1/0/2 10GE1/0/1
VLANIF101 VLANIF300
10.110.1.2/24 192.168.3.1/24
Loopback0
10.5.5.5/32 10.2.2.2/32
10.110.1.1/24 Loopback0 192.168.3.2/24
VLANIF101 VLANIF300
10GE1/0/2 192.168.1.1/24 10GE1/0/1
VLANIF100
Loopback1 10GE1/0/1 10GE1/0/2
10.3.3.3/32 VLANIF100
10GE1/0/3 192.168.1.2/24
SwitchC VLANIF104 SwitchE
Loopback10 10.110.4.1/24
10.1.1.1/32
User1
MSDP peers
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 Open Shortest
Path First (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
Loopback10 as a rendezvous point (RP) and Loopback1 as a candidate bootstrap router
(C-BSR)
4. Configure MSDP peers on Loopback0 interfaces of SwitchC and SwitchD. According to
reverse path forwarding (RPF) rules, the switches receive Source-Active (SA) messages
from the source RP.
Procedure

# According to Figure 4-12, 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.
[*SwitchC-Vlanif104] igmp enable
[*SwitchC] commit
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
[*SwitchC] commit
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 10.2.2.2 connect-interface loopback0
[*SwitchC-msdp] quit
[*SwitchC] commit
# Configure an MSDP peer on Loopback0 of SwitchD.

[~SwitchD] interface loopback 0
[*SwitchD-LoopBack0] ip address 10.2.2.2 255.255.255.255
[*SwitchD-LoopBack0] pim sm
[*SwitchD-LoopBack0] quit
[*SwitchD] msdp
[*SwitchD-msdp] originating-rp loopback0
[*SwitchD-msdp] peer 10.5.5.5 connect-interface loopback0

[*SwitchD-msdp] quit
[*SwitchD] commit

The following output shows summary information about MSDP peers on SwitchC and
SwitchD:
---------------------------------------------------------------------------------
Configured Up Listen Connect Shutdown

Down
1 1 0 0 0
0
---------------------------------------------------------------------------------
Peer's Address State Up/Down time AS SA Count Reset

Count
10.2.2.2 Up 00:10:17 ?(unknown) 0
0
[~SwitchD] display msdp brief

---------------------------------------------------------------------------------
Configured Up Listen Connect Shutdown

Down
1 1 0 0 0
0
---------------------------------------------------------------------------------
Peer's Address State Up/Down time AS SA Count Reset

Count
10.5.5.5 Up 00:10:18 ?(unknown) 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:08:49
1: Vlanif104
(10.110.5.1, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:07:26


1: Vlanif104
Not output is displayed.

# 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] quit
<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.
<SwitchC> display pim routing-table
Not output is displayed.

(*, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:07:23
1: Vlanif103,
(10.110.6.100, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:05: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
#
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
#
vlan batch 100 to 101 104
#
#
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
#
interface LoopBack0
ip address 10.5.5.5 255.255.255.255
pim sm
#
interface LoopBack1
ip address 10.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 10.5.5.5 0.0.0.0
network 10.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 10.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 10.2.2.2 255.255.255.255
pim sm
#
interface LoopBack1
ip address 10.4.4.4 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 10.2.2.2 0.0.0.0
network 10.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 10.5.5.5 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.11.4 Example for Configuring SA Message Filtering

As shown in Figure 4-13, 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
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-13 Network diagram for configuring SA message filtering
PIM-SM1
PIM-SM2
10.1.1.1/32
Loopback0 10.2.2.2/32
192.16 Loopback0
10.110.1.1/24 8.1
VLANIF100 VLANIF.1/24 192.16
10GE1/0/1 10GE1 101 VLANIF8.1.1/24 10.110.4.1/24
Receiver
/0/3 HostB
10GE1 101 VLANIF300
/0/3 10GE1/0/1
HostA SwitchA 10GE1/0/2 4
Receiver VLANIF102 /0/
10.110.2.1/24 G E1 103 SwitchC
10.110.2.2/24 10 NIF /24
A .2 10GE1/0/2
VLANIF102 VL 68.2 VLANIF104
3 1
Source1 10GE1/0/2 /0/ 2 .
G E1 103 19 10.110.5.1/24
10 NIF /24
10GE1/0/1 A 1
VLANIF200 VL 8.2.
1 6
10.110.3.1/24 2.
19
SwitchB Loopback0 10.110.5.2/24
VLANIF104
10.3.3.3/32 10GE1/0/2
10GE1/0/3 10GE1/0/1
VLANIF400 VLANIF500
10.110.6.1/24 SwitchD 10.110.7.1/24
HostC
MSDP peers Receiver
Source2
PIM-SM3
Configure MSDP to implement multicast source information sharing among domains.
Configure Source-Active (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 candidate

bootstrap router (C-BSR) and the candidate rendezvous point (C-RP) of each PIM-SM
domain.
4. Set up MSDP peer relationships between RPs in PIM-SM 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.
Procedure
# According to Figure 4-13, 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-Vlanif103] pim bsr-boundary
[*SwitchC-Vlanif104] 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
[*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
[*SwitchD-msdp] commit
[~SwitchD-msdp] quit
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 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-msdp] quit
[*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
(10.110.3.100, 225.1.1.0)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:03:32, Expires: 00:05:28
(10.110.3.100, 225.1.1.1)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:03:32, Expires: 00:05:28
(10.110.3.100, 225.1.1.2)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:03:32, Expires: 00:05:28
(10.110.3.100, 225.1.1.3)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:03:32, Expires: 00:05:28
(10.110.3.100, 226.1.1.0)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:03:32, Expires: 00:05:28
(10.110.3.100, 226.1.1.1)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:03:32, Expires: 00:05:28
(10.110.3.100, 226.1.1.2)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:03:32, Expires: 00:05:28
(10.110.3.100, 226.1.1.3)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:03:32, Expires: 00:05:28
[~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
(10.110.3.100, 226.1.1.0)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:24:53, Expires: 00:05:06
(10.110.3.100, 226.1.1.1)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:24:53, Expires: 00:05:06
(10.110.3.100, 226.1.1.2)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:24:53, Expires: 00:05:06
(10.110.3.100, 226.1.1.3)
Origin RP: 10.1.1.1
Pro: BGP, AS: ?
Uptime: 00:24:53, Expires: 00:05:06

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
group 226.1.1.0/30 exists in the SA cache on SwitchD.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 to 102
#
#
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 10.1.1.1 255.255.255.255
pim sm
#
ospf 1
area 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.2.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
msdp
#
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 to 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
#
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 10.2.2.2 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.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 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
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface LoopBack0

ip address 10.3.3.3 255.255.255.255

pim sm
#
ospf 1
area 0.0.0.0
network 10.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
4.12 Troubleshooting MSDP
4.12.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.
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.12.2 There Is No (S, G) Entry in the SA Cache
Fault Description
MSDP fails to send (S, G) entries through Source-Active (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
from each other.
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.12.3 RPs Fail to Exchange Registration Information with Each

Other
Fault Description
Rendezvous points (RPs) in the anycast RP application fail to exchange (S, G) information
registered to a local device with each other.
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
candidate bootstrap router (C-BSR) and candidate rendezvous point (C-RP) must be
configured on two devices or interfaces.
l An MSDP peer performs a reverse path forwarding (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
from each other.
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

Configuration Guide - IP Multicast 5 IPv4 Multicast Route Management Configuration
5 IPv4 Multicast Route Management

Configuration
This chapter explains the multicast protocols that a switch can use to control multicast routing
and forwarding, by exchanging messages between the control plane and the forwarding plane.
In this chapter, the word "router" and the router icon used in figures refer to a conventional router or
Layer 3 switch.
5.1 Overview of IPv4 Multicast Route Management

5.2 Understanding IPv4 Multicast Route Management
5.3 Summary of IPv4 Multicast Route Management Configuration Tasks
5.4 Licensing Requirements and Limitations for IPv4 Multicast Route Management
5.5 Default Settings for IPv4 Multicast Route Management
5.6 Configuring RPF Check Policies
5.7 Configuring an IPv4 Multicast Boundary
5.8 Disabling Software Forwarding for IPv4 Multicast Packets
5.9 Maintaining IPv4 Multicast Routes
5.10 Configuration Examples for IPv4 Multicast Route Management
5.11 Troubleshooting IPv4 Multicast Route Management
5.1 Overview of IPv4 Multicast Route Management

Definition
Multicast route management refers to the control of multicast packet forwarding by creating
or changing multicast routes, as well as checking and maintaining multicast forwarding paths.

Purpose
Multicast route management ensures that multicast packets are forwarded efficiently through
the correct paths.
In multicast routing and forwarding, each multicast routing protocol creates and maintains its
own routing table. The routing information from these tables is then used to create a general
multicast routing table. Multicast routers use this general multicast routing table to determine
optimal routes, according to multicast routing and forwarding policies. The optimal route
information is then delivered to the multicast forwarding information base (MFIB), where
multicast data forwarding is controlled.
The MFIBs of network devices maintain a point-to-multipoint forwarding tree for the entire
network, with a multicast source as the root and group members as leaves. Table 5-1
describes functions of multicast route management.
Table 5-1 Multicast route management functions

Function Description
Reverse Path Forwarding (RPF) check Ensures that multicast data is forwarded
through correct paths.
Multicast static route Changes or connects multicast RPF routes.
Multicast load splitting Distributes multicast data to multiple equal-

cost routes to reduce the load on individual
paths.
Multicast nonstop routing (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.
5.2 Understanding IPv4 Multicast Route Management
5.2.1 Multicast Routing and Forwarding

Devices performing different roles on a multicast network maintain different multicast tables,
including the Internet Group Management Protocol (IGMP) group table, multicast protocol
routing table, multicast routing table, and multicast forwarding information base (MFIB). The
following sections describe the functions of these tables in multicast route management.
IGMP Group
A multicast router creates an IGMP group entry when it receives an IGMP Join message from
a host. The router maintains group memberships in IGMP group entries and instructs a
multicast routing protocol, usually the Protocol Independent Multicast (PIM) protocol, to
create corresponding (*, G) entries. The router maintains an IGMP group entry for each
interface provided that the interfaces have IGMP enabled and have received IGMP Join
messages.

The following is an example of a group entry on an interface:

<HUAWEI> display igmp group
Interface group report information of VPN instance: public net
Vlanif100(10.1.6.2):
Total 1 IGMP Group reported
Group Address Last Reporter Uptime Expires
225.1.1.2 10.1.6.10 00:02:04 00:01:17
Table 5-2 explains the fields of this IGMP group entry.
Table 5-2 Description of fields in the IGMP group entry

Field Description
Group Address Indicates the address of the group that an interface has
joined.
Last Reporter Indicates the IP address of the last user that sent an
IGMP Join message to the group.
Uptime Indicates the time elapsed since the group was

created.
Expires Indicates the time remaining before the group will be

aged out.
Multicast Protocol Routing Table

Multicast routing protocols maintain their own routing tables to guide multicast route
management. PIM is the most widely used multicast routing protocol. The following is an
example of a PIM routing table:
<HUAWEI> display pim routing-table
(192.168.0.12, 227.0.0.1)
RP: 10.2.2.2
UpTime: 02:54:43
Upstream interface: Vlanif 10
1: Vlanif 20
Table 5-3 explains the fields in this PIM routing entry.
Table 5-3 Description of fields in the PIM routing entry

Field Description
(192.168.0.12, 227.0.0.1) (S, G) entry, where 192.168.0.12 is the source address

and 227.0.0.1 is the group address.
RP: 10.2.2.2 Indicates the rendezvous point (RP) IP address.

Field Description
Protocol: pim-sm The first Protocol field in an entry indicates the

protocol that generates the entry, and the second
Protocol field indicates the protocol that generates the
downstream interfaces.
Flag: SPT LOC ACT Indicates the flag of the PIM routing entry.
UpTime: 02:54:43 The first UpTime field in an entry indicates how long
the entry has existed, and the second UpTime field
indicates how long a downstream interface has
existed.
Upstream interface: Vlanif 10 Indicates the upstream interface pointing to the

multicast source.
Upstream neighbor: NULL NULL indicates that no upstream neighbor is

available.
RPF prime neighbor: NULL NULL indicates that no reverse path check (RPF)
neighbor is available.
Downstream interface(s) Indicates information about downstream interfaces

information: toward receivers.
Total number of downstreams: 1 Indicates the number of downstream interfaces.
Expires: 00:02:47 Indicates the aging time of a downstream interface.
For details about PIM routing entries, see 3.2.1 Concepts in the PIM feature description.
Multicast Routing Table

A multicast routing table is generated and maintained by the multicast route management
module of a router. If a router supports multiple multicast protocols, its multicast routing table
contains the optimal routes selected from the routing tables of these protocols.
In unicast routing, routing tables of various routing protocols, such as Open Shortest Path
First (OSPF), Routing Information Protocol (RIP), and Border Gateway Protocol (BGP),
constitute an IP routing table. Similarly, routing tables of different multicast protocols
constitute a multicast table. Routers deliver multicast routing entries to their MFIBs to guide
multicast data forwarding. The following is an example of a multicast routing table:
<HUAWEI> display multicast routing-table
Multicast routing table of VPN instance: public net
00001: (192.168.0.2, 227.0.0.1)

Uptime: 00:00:28
Upstream Interface: Vlanif10
List of 2 downstream interfaces
1: Vlanif20
2: Vlanif30
Table 5-4 explains the fields in this multicast routing entry.

Table 5-4 Description of fields in the multicast routing entry
Field Description
00001: (192.168.0.2, 227.0.0.1) 00001 is the entry number, and (FC00::2, FFE3::1) is
an (S, G) entry, where S indicates a source address
and G indicates a group address.
Uptime: 00:00:28 Indicates the time elapsed since the multicast routing
entry was updated.
Upstream Interface: Indicates the upstream interface pointing to the

VlanifIndicates the 10 multicast source.
List of 2 downstream interfaces Indicates the downstream interfaces toward receivers.
MFIB
An MFIB is created and maintained by the route management module of a router according to
multicast routing information. Routers forward multicast data according to their MFIBs. You
can use the display multicast ip fib command to view entries in an MFIB. An MFIB has the
same functions as a unicast FIB. The following is an example of an MFIB.
<HUAWEI> display multicast ip fib
Multicast Forwarding Table of VPN-Instance: public net
Total 1 entry, 1 matched
1.(10.10.10.2, 225.0.0.1)
Index : 10
Flags : 1
Timeout: 00:03:26
Incoming interface : Vlanif10
Outgoing Interfaces: 2
1: Vlanif20
1: Vlanif30
Matched packets :34640 packets(3602664 bytes)
Wrong interface :0 packets
Forwarded :34640 packets(3602664 bytes)
Table 5-5 explains the fields in this multicast forwarding entry.
Table 5-5 Description of fields in the multicast forwarding entry
Field Description
1. (10.10.10.2, 225.0.0.1) 1 is the entry number, and (10.10.10.2, 225.0.0.1) is

an (S, G) entry, where S indicates a source address
and G indicates a group address.
Index : 10 Indicates the unique identifier of the multicast

forwarding entry in the MFIB. It is used to rapidly
search the MFIB.
Flags : 1 Indicates the flag of the multicast forwarding entry.
Timeout: 00:03:26 Indicates how soon the multicast forwarding entry

will time out.

Field Description
Incoming interface: Vlanif10 Indicates the inbound interface in the multicast

forwarding entry.
Outgoing Interfaces: 2 Lists the outbound interfaces toward receivers.
Matched packets :34640 Indicates the number of packets of packets that match
packets(3602664 bytes) the multicast forwarding entry.
Wrong interface :0 packets Indicates the number of packets that arrive on the
incorrect inbound interfaces.
Forwarded :34640 Indicates the number of forwarded packets.

packets(3602664 bytes)
The preceding information shows that multicast data is forwarded according to the MFIB.
Each multicast forwarding entry records statistics about packets that are forwarded according
to the entry.
5.2.2 RPF Check
RPF Check Basics

In unicast routing and forwarding, unicast packets are transmitted along a point-to-point path.
Routers only need to know the destination address of a packet to find the outbound interface.
In multicast routing and forwarding, however, routers cannot know the location of a specific
receiver because the destination address of a multicast packet identifies a group of receivers.
Because routers can find out the source of a multicast packet based on the source address,
they can check the source addresses of multicast packets to ensure correct forwarding paths.
The process of checking the forwarding path based on the source address is a reverse path
forwarding (RPF) check.
When a router receives a multicast packet, it searches the unicast routing table for the route to
the source address of the packet. After finding the route, the router checks whether the
outbound interface for the route is the same as the inbound interface of the multicast packet. If
they are the same, the router considers that the multicast packet has been received from a
correct interface. This ensures correct forwarding paths for multicast packets.
The correct interface is called an RPF interface.
RPF Check Process

In addition to unicast routes, RPF checks can also be performed using Multiprotocol Border
Gateway Protocol (MBGP) routes and static multicast routes. If a router has all these routes, it
performs an RPF check on a multicast packet in the following way:
1. The router selects an optimal route from each of the unicast routing table, MBGP routing
table, and multicast static routing table according to the source address of the multicast
packet. The outbound interfaces of the unicast and MBGP routes are RPF interfaces, and
the next hops of those routes are the RPF neighbors. The RPF interface and RPF
neighbor of the multicast static route have been specified when the route is manually
configured.

2. The router selects one of the three routes as the RPF route according to the following
rules:
– If the longest match rule is configured, the router selects the route with the longest
mask. If more than one route has the longest mask, the router selects the one with
the highest preference. If more than one route has the highest preference, the router
uses the following order of priority: multicast static route, MBGP route, and unicast
route.
– If the longest match rule is not configured, the router selects the route with the
highest preference. If more than one route has the highest preference, the router
uses the following order of priority: multicast static route, MBGP route, and unicast
route.
3. The router compares the inbound interface of the packet with the RPF interface of the
selected RPF route. If the inbound interface is the same as the RPF interface, the router
considers that the packet has arrived on the correct path from the source and forwards the
packet downstream. If the inbound interface is different from the RPF interface, the
packet fails the RPF check. The router considers that the packet is received from an
incorrect interface and drops the packet.
In Figure 5-1, a multicast stream sent from source 10.10.2.2 arrives at interface Int1 of the
router. The router checks the routing table and finds that the multicast stream from this source
should arrive at interface Int0. The RPF check fails, and the router drops the multicast stream.
Figure 5-1 RPF check fails

IP Routing Table
Network Interface
Multicast stream
10.10.0.0/16 Int0 from source
192.168.1.0/24 Int1 10.10.2.2
192.168.2.0/24 Int2
Int1
Int0 Int2
In Figure 5-2, a multicast stream sent from the source 10.10.2.2 arrives at interface Int0 of the
router. The router checks the routing table and finds that the RPF interface is also Int0. The
RPF check succeeds, and the multicast stream is correctly forwarded.

Figure 5-2 RPF check succeeds

IP Routing Table
Network Interface
10.10.0.0/16 Int0
192.168.1.0/24 Int1
192.168.2.0/24 Int2
Multicast stream Int1

from source Int0 Int2
10.10.2.2
RPF Check in Multicast Data Forwarding

Multicast routing protocols determine upstream and downstream neighbors and create
multicast routing entries based on unicast routes, MBGP routes, and multicast static routes.
The RPF check mechanism enables multicast data streams to be transmitted along the
multicast distribution tree and prevents loops on forwarding paths.
If a router searches the unicast routing table to perform an RPF check on every multicast data
packet received, many system resources are consumed. To save system resources, a router
first searches for the matching (S, G) entry after receiving a data packet sent from a source to
a group.
l If no matching (S, G) entry is found, the router performs an RPF check to find the RPF
interface for the packet. The router then creates a multicast route with the RPF interface
as the upstream interface and delivers the route to the multicast forwarding information
base (MFIB). If the RPF check succeeds, the inbound interface of the packet is the RPF
interface, and the router forwards the packet to all the downstream interfaces in the
forwarding entry. If the RPF check fails, the packet has been forwarded along an
incorrect path, so the router drops the packet.
l If a matching (S, G) entry is found and the inbound interface of the packet is the same as
the upstream interface in the entry, the router replicates the packet to all downstream
interfaces specified in the entry.
l If a matching (S, G) entry is found but the inbound interface of the packet is different
from the upstream interface in the entry, the router performs an RPF check on the packet.
Based on the RPF check result, the router processes the packet as follows:
– If the RPF interface is the same as the upstream interface in the entry, the (S, G)
entry is correct and the packet has been forwarded along an incorrect path. The
router drops the packet.
– If the RPF interface is different from the upstream interface in the entry, the (S, G)
entry is outdated, and the router changes the upstream interface in the entry to be
the same as the RPF interface. The router then compares the RPF interface with the
inbound interface of the packet. If the inbound interface is the RPF interface, the
router replicates the packet to all downstream interfaces specified in the (S, G)
entry. If the inbound interface is different from the RPF interface, the router drops
the packet.

5.2.3 Multicast Static Route

RPF checks can be performed using multicast static routes. Multicast static routes can be used
to change and connect RPF routes.
Changing RPF Routes

You can change RPF routes on a network by configuring multicast static routes. Multicast
data can then be transmitted along a different path from unicast data.
In Figure 5-3, RouterA is the RPF neighbor of RouterC towards the multicast source
(Source). Multicast packets sent from Source are transmitted along the path Source →
RouterA → RouterC. If you configure a multicast static route on RouterC and specify
RouterB as the RPF neighbor, the transmission path of multicast packets sent from Source
changes to Source → RouterA → RouterB → RouterC. In this way, the multicast path
diverges from the unicast path.
Figure 5-3 Configuring a multicast static route to change the RPF route
Multicast Routing Table on RouterC
Source/Mask Interface RPF Neighbor/Mask
192.168.1.1/24 Int0 10.2.2.1/24
Receiver
RouterB
Int0
10.2.2.1/24
Source Int0 Receiver
10.2.2.2/24
Int1
192.168.1.1/24 RouterA
RouterC
Multicast stream
Multicast static route
Connecting RPF Routes

When unicast routes on a multicast network are incomplete, multicast packets cannot be
forwarded due to a lack of an RPF route. In this case, multicast static routes can be configured
on the network to generate new RPF routes. Multicast routers then create new multicast
forwarding entries to guide multicast data forwarding.
In Figure 5-4, Domain1 and Domain2 are routing domains (RIP and OSPF domains for
example). The domains have no unicast route to each other, so receivers in Domain2 cannot
receive data from the multicast source in Domain1. To enable receivers to receive data from
the multicast source, configure multicast static routes on RouterC and RouterD in Domain2.
On RouterC, specify RouterB as the RPF neighbor. On RouterD, specify RouterC as the RPF
neighbor.

Figure 5-4 Configuring multicast static routes to connect RPF routes

Multicast Routing Table on RouterC
192.168.1.1/24 Int1 10.3.3.1/24
Multicast Routing Table On RouterD Domain2

RouterD Receiver
192.168.1.1/24 Int0 10.2.2.2/24
Int0
10.2.2.1/24
Domain1
Source 10.3.3.1/24 10.3.3.2/24 Int0
10.2.2.2/24
Int0 Int1
192.168.1.1/24 RouterA RouterB RouterC Receiver
Multicast stream
Multicast static routes are local to the router where they are configured and are not advertised or
redistributed to any other router.
5.2.4 Multicast Load Splitting

Load splitting is different from load balancing. Load splitting provides a way to distribute
data streams destined for the same destination to multiple equal-cost paths, which may not
result in a balanced traffic load on the paths. Load balancing is a special form of load splitting
and distributes even data traffic loads on multiple equal-cost paths.
Implementation
By default, a router selects an RPF route from multiple equal-cost optimal routes to forward
multicast packets according to the following RPF check policy:
l If the equal-cost routes are in the same routing table, for example, a unicast routing table,
multicast static routing table, or MBGP routing table, the router 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 router selects the route with the
highest preference. If multiple routes have the highest preference, the router selects the
route with the longest mask length. If multiple routes have the longest mask length, the
router uses an algorithm to select a route as the RPF route.
In this default configuration, the router selects only one route as the RPF route, regardless of
which condition is met.
Multicast load splitting enables a router to distribute multicast traffic to multiple equal-cost
routes, instead of selecting only one route based on the RPF check policy.

As shown in Figure 5-5, the multicast source (Source) sends multicast streams to group G.
RouterA and RouterD run an Interior Gateway Protocol (IGP), OSPF for example, to
implement IP interworking. Two equal-cost paths are available: RouterA → RouterB →
RouterD and RouterA → RouterC → RouterD. Based on the default RPF check policy,
multicast streams are forwarded through interface Int0 of RouterA because Int0 has a larger
IP address than Int1. After multicast load splitting is configured on RouterA, RouterA does
not select forwarding paths by comparing the next-hop IP addresses. Instead, multicast
streams are forwarded along both of the two equal-cost paths.
Figure 5-5 Multicast forwarding without and with multicast load splitting
Multicast network without load splitting
RouterB
Source Receiver
Int0 10.1.2.1 RouterD
Int1 10.1.1.1
RouterA
RouterC
Multicast network with load splitting
RouterB
Source Receiver
Int0 10.1.2.1 RouterD
Int1 10.1.1.1
RouterA
RouterC
Multicast Packets
Multicast Load Splitting Modes

Various methods are available to split (*, G) and (S, G) data streams in different scenarios.

l Load splitting by group address

In Figure 5-6, the source sends data streams to different multicast groups (G1 to G10).
Router7, Router6, and Router5 each have two equal-cost paths to the source. These
routers use route selection algorithms to select an optimal path for data sent to each
group. In this load splitting mode, streams transmitted on different paths are sent to
different groups.
Figure 5-6 Load splitting by group address

Router1
Router5 Receiver
Router2
(S, G1)
(S, G2) Source
. Router7
. Router3
.
(S, G10) Router6
Router4
l Load splitting by source address

In Figure 5-7, different sources (S1 to S10) send data streams to the same group.
Router7, Router6, and Router5 each have two equal-cost paths to the sources. These
routers use route selection algorithms to select an optimal path for data from each source.
In this load splitting mode, streams transmitted on different paths are sent from different
sources.
Figure 5-7 Load splitting by source address
Router1
Source1 Receiver
Router5
(S1, G)
Router2
. Router7
.
. Router3
Router6
Source10
Router4
(S10, G)
l Load splitting by source address and group address

In Figure 5-8, different sources (S1 to S10) send data streams to different groups (G1 to
G10). Router7, Router6, and Router5 each have two equal-cost paths to the sources.
These routers use route selection algorithms to select an optimal path for each (S, G)
stream. In this load splitting mode, streams transmitted on different paths have different
source and group addresses.

Figure 5-8 Load splitting by source address and group address
Router1
Source1 Receiver
Router5
(S1, G1)
Router2
. Router7
.
. Router3
Router6
Source10
Router4
(S10, G10)
l Other load splitting methods
Figure 5-9 Load splitting network
Router1
Source
Router5 Receiver
Router2
Router7
Router3
Router6
Router4
The following load balancing methods can also be used on the network shown in Figure
5-9:
– Stable-preferred load splitting
When route flapping occurs on a multicast network, frequent changes of multicast
traffic distribution on equal-cost paths will cause the route flapping to become
worse. Stable-preferred load splitting can be configured to solve this problem.
When route flapping occurs, a router with stable-preferred load splitting adjusts
traffic distribution on equal-cost paths until route flapping ends. When the network
topology becomes stable, the router evenly distributes (S, G) streams from the same
source to equal-cost paths.
– Load splitting by link bandwidth
Transmission paths on a network have different capabilities. If routing entries are
evenly distributed on the equal-cost paths, the bandwidth of each path cannot be
fully leveraged. After this load splitting mode is configured, routing entries can be
distributed on paths based on link bandwidth.

5.2.5 Multicast NSR

Non-stop routing (NSR) is a reliability technology applied to a system with double control
planes. (The system can be a standalone device with double main control units or a stack
system with master and standby member devices. The following descriptions use a standalone
device with double main control units as an example). This technology shields switchovers
between system control planes from the routing protocol control plane. When a switchover
occurs between the main control units on a device, its neighbors are unaware of the
switchover.
For details about NSR, see "NSR" in the CloudEngine 6800 Series Switches Configuration
Guide - Reliability.
Multicast NSR is enabled on the device by default and does not need to be configured.
Fundamentals
IP multicast services, such as IPTV, video conferencing, and tele-education, require high
network reliability. Without the multicast NSR technology, multicast forwarding is interrupted
if a device on a multicast network experiences an active/standby switchover.
Multicast NSR technology can ensure non-stop multicast forwarding during an active/standby
switchover. When the standby main control unit starts, multicast NSR starts to back up
multicast routing information and multicast protocol control information (including neighbor,
multicast distribution tree, RP set, and user access information) to the standby main control
unit. When a switchover occurs between the active and standby main control units, multicast
data can still be forwarded according to the backup multicast routing information. In addition,
the local device maintains the PIM neighbor relationships using the backup protocol control
information so that neighbors are unaware of the switchover. Backup of multicast routing
information and multicast protocol control information ensures non-stop multicast routing,
delivering high reliability for multicast services.
Implementation
On IPv4 multicast networks, multicast NSR can be implemented for the Internet Group
Management Protocol (IGMP), Multicast Source Discovery Protocol (MSDP), and Protocol
Independent Multicast (PIM). Multicast NSR involves the following mechanisms:
1. Batch backup
When the standby main control unit starts, the active main control unit backs up all
multicast routing information and multicast protocol control information to the standby
main control unit, ensuring consistent information on the two main control units.
2. Real-time backup
During operation of multicast protocols, the active main control unit backs up changed
multicast routing information and multicast protocol control information to the standby
main control unit in real time, ensuring data synchronization between the two main
control units.
3. Switchover
If the active main control unit fails, the standby main control unit takes over services.
The standby main control unit saves the same multicast routing information and

multicast protocol control information as the active main control unit, so multicast
forwarding is not interrupted during the switchover.
5.3 Summary of IPv4 Multicast Route Management

Configuration Tasks
Table 5-6 lists IPv4 multicast route management configuration tasks.
Table 5-6 IPv4 multicast route management configuration tasks

Task Description
5.6 Configuring RPF Check Policies Applies different route selection policies to
adapt to different multicast service
scenarios.
5.7 Configuring an IPv4 Multicast Restricts the scope of multicast forwarding.

Boundary
5.8 Disabling Software Forwarding for Prevents packet loss and mis-sequencing
IPv4 Multicast Packets caused by software forwarding.
5.4 Licensing Requirements and Limitations for IPv4

Multicast Route Management

a multicast source.


IPv4 multicast route management is a basic software function of the switch. The license for
basic software functions has been loaded and activated before delivery. You do not need to
manually activate it.

Required
CE5810EI V100R002C00
CE5850EI V100R001C00
CE5850HI V100R003C00
CE5855EI V100R006C00
CE5880EI V200R005C10
CE6810EI V100R003C00
CE6850EI V100R001C00
CE6850-48S6Q-HI V100R005C00
CE6855HI V200R001C00
CE6856HI V200R002C50
CE6857EI V200R005C10
CE6860EI V200R002C50
CE6865EI V200R005C00
CE6870-48T6CQ-EI V200R002C50
CE6875EI V200R003C00
CE6880EI V200R002C50
CE6881/CE6820/CE6863 V200R005C20
CE7850EI V100R003C00


Required
CE7855EI V200R001C00
CE8850-32CQ-EI V200R002C50
CE8850-64CQ-EI V200R005C00
CE8860EI V100R006C00
CE8861EI/CE8868EI V200R005C10
Feature Limitations
l In the scenario where Fast Channel Change (FCC) is enabled, it is recommended that
you use the multicast cpu-forward disable command to disable soft forwarding for
multicast packets.
1000 to 2000 1000 seconds
2000 to 8000 2000 seconds
following points:
other services
Item Precautions
deployed with
M-LAG

Item Precautions
In V100R006C00 and later versions, an M-LAG set up with


5.5 Default Settings for IPv4 Multicast Route Management

Table 5-9 lists the default settings for IPv4 multicast route management.
Table 5-9 Default settings for IPv4 multicast route management

Longest match rule for Not configured. The reverse path forwarding (RPF) route is
multicast route selection selected based on router preference during an RPF check.
Multicast load splitting Disabled. Only one route is selected to forward multicast
packets.
Multicast boundary Not configured.
5.6 Configuring RPF Check Policies
Before configuring an RPF check policy, complete the following tasks:
l Run the multicast routing-enable command in the system view to enable Layer 3
multicast routing globally.
The following configuration tasks can be performed in any sequence.
5.6.1 Configuring a Multicast Static Route
Context
A multicast static route specifies a reverse path forwarding (RPF) interface or RPF neighbor
for multicast packets from a specified multicast source. 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 that 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 an RPF check using the configured RPF route. Packets sent from the source to
the switch through other interfaces fail the RPF check.
l Connect RPF routes.
If the unicast route on a network segment is incomplete, multicast packets cannot be
forwarded because there is no 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 an RPF check using
the specified RPF interfaces so that multicast packets can be forwarded successfully.

Procedure
Step 2 Run ip rpf-route-static [ vpn-instance vpn-instance-name ] source-address { mask | mask-
length } { gateway-address | interface-type interface-number } [ preference preference ]
A multicast static route is configured.
Step 3 Run commit
----End
5.6.2 Configuring Longest Match for Multicast Route Selection
Context
By default, a switch selects reverse path forwarding (RPF) routes based on route preference.
If you change the RPF check policy to longest match, the switch compares mask lengths of
routes to select an RPF route, and compares route preference when multiple routes have the
longest mask length.
Procedure
Step 2 Run multicast longest-match
The longest match rule is applied for route selection.
Step 3 Run commit
----End
5.6.3 Configuring IPv4 Multicast Load Splitting

Context
By default, if there are multiple equal-cost routes to a multicast source, a switch applies the
following route selection rules during a reverse path forwarding (RPF) check:
l If the equal-cost routes are in the same routing table, for example, a unicast routing table,
multicast static routing table, or Multiprotocol Border Gateway Protocol (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 multiple routes have the highest preference, the switch selects
the route with the longest mask length. If multiple routes have the longest preference, the
switch uses an algorithm to select an RPF route.

In this default configuration, the switch selects only one route as the RPF route, regardless of
which condition is met. Multicast load splitting enables the switch to distribute multicast data
among multiple equal-cost paths based on a specific load splitting policy. This function
improves quality of multicast forwarding.
Procedure
Step 2 Run multicast load-splitting { balance-ucmp | stable-preferred | source | group | source-

group }
Multicast load splitting is configured.
The keywords in the command specify different multicast load splitting policies:
l balance-ucmp: ensures even load distribution among forwarding paths. This policy
selects (*, G) or (S, G) entries based on forwarding capabilities of outbound interfaces on
the equal-cost routes.
l stable-preferred: ensures stable multicast forwarding. Use this policy on a network with
stable multicast services.
If this load splitting policy is used, the switch automatically adjusts traffic on equal-cost
routes when equal-cost routes are added or deleted. However, 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 by group address. Use this policy in scenarios where one multicast
source sends data to multiple groups.
l source: load splitting by source address. Use this policy in scenarios where one group
receives data from multiple sources.
l source-group: load splitting by source address and group address. Use this policy in
scenarios where multiple sources send data to multiple groups.
Step 3 Run commit
----End
5.6.4 Verifying the RPF Check Policy Configuration
Context
After changing the reverse path forwarding (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 [ vpn-instance vpn-instance-name ] static
[ config ] [ source-address { mask | mask-length } ] command to check the multicast
static routing table.

l Run the following commands to check the multicast routing table:

– display multicast routing-table [ group-address [ mask { group-mask | group-
mask-length } ] | source-address [ mask { source-mask | source-mask-length } ] |
| none } ] * [ outgoing-interface-number [ number ] ]
– display multicast { vpn-instance vpn-instance-name | all-instance } routing-table
match } { interface-type interface-number | register | none } ] * [ outgoing-
l Run the following commands to check the RPF route to a specified multicast source:
– display multicast rpf-info source-address [ group-address ] [ rpt | spt ] [ verbose ]
– display multicast { vpn-instance vpn-instance-name | all-instance } rpf-info
source-address [ group-address ] [ rpt | spt ]
----End
5.7 Configuring an IPv4 Multicast Boundary
Before configuring the multicast boundary, complete the following tasks:
Context
To restrict forwarding of multicast packets sent to a multicast group within a range, configure
a multicast boundary on interfaces. Once the multicast boundary is configured on an interface,
multicast packets sent to the group cannot be forwarded through the interface.
Procedure

1. Run quit
interface.
Step 5 Run multicast boundary group-address { mask | mask-length }
A multicast boundary is configured on the interface.
Step 6 Run commit
----End

After configuring a 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.

l Run the display multicast [ vpn-instance vpn-instance-name | all-instance ] boundary

[ group-address [ mask | mask-length ] ] [ interface interface-type interface-number ]
command to check information about the multicast boundary configured on an interface.
5.8 Disabling Software Forwarding for IPv4 Multicast

Packets
Before disabling software forwarding for multicast packets, complete the following tasks:
Context
In most cases, a switch forwards packets performs software forwarding before hardware
forwarding entries are generated. After hardware forwarding entries are generated, the switch
performs hardware forwarding.
Soft forwarding for multicast packets must be disabled on the switch to prevent the low
forwarding speed and first packet cache mechanism of soft forwarding from causing disorder
of the first packet transmitted at a high speed.
Procedure
Step 2 Run multicast cpu-forward disable
Soft forwarding is disabled for multicast packets.
By default, software forwarding for multicast packets is enabled.
In the scenario where Fast Channel Change (FCC) is enabled, it is recommended that you use
the multicast cpu-forward disable command to disable soft forwarding for multicast
packets.
Step 3 Run commit
----End
5.9 Maintaining IPv4 Multicast Routes

Context
You can monitor multicast routing and forwarding, and configure the maximum number of
invalid IPv4 multicast protocol packets that a switch can store.
5.9.1 Monitoring IPv4 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 tables.
Procedure
l Run the display multicast [ vpn-instance vpn-instance-name | all-instance ] boundary
[ group-address [ mask | mask-length ] ] [ interface interface-type interface-number ]
command to check the multicast boundary configured on an interface.
l Run the display multicast ip fib [ [ vpn-instance vpn-instance-name ] [ group group-
address | source source-address | incoming-interface { interface-type interface-number |
register } ]* | all-vpn-instance ] command to check the MFIB.
l Run the display multicast routing-table [ vpn-instance vpn-instance-name ] static
[ config ] [ source-address { mask-length | mask } ] command to check the multicast
static routing table.
l Run the following commands to check the RPF route to a specified multicast source:
– display multicast [ vpn-instance vpn-instance-name | all-instance ] rpf-info
source-address [ group-address ] [ rpt | spt ] [ verbose ]
----End
5.9.2 Configuring the Maximum Number of Invalid IPv4

Multicast Protocol Packets That a Switch Can Store
Context
If multicast forwarding entries or Multicast Source Discovery Protocol (MSDP) peer
relationships cannot be established on a network, you can configure the maximum number of
invalid multicast protocol packets that the switches can store. Then check statistics and details
about invalid multicast packets for troubleshooting.

Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the multicast invalid-packet { igmp | mdt | msdp | pim } max-count max-number
command to set the maximum number of invalid multicast protocol packets that the switch
can store.
By default, a switch can store a maximum of 10 invalid packets for each multicast protocol.
Step 3 Run the commit command to commit the configuration.
----End

After completing the configuration, run the following commands to check the maximum
number of invalid IPv4 multicast protocol packets that can be saved and statistics about
invalid multicast protocol packets:
l Run the display current-configuration | include multicast invalid-packet command to

check the maximum number of invalid multicast protocol packets that the switch can
store.
l Run the following commands to check the statistics about various invalid multicast
protocol packets saved on the switch:
– Run the display igmp [ vpn-instance vpn-instance-name | all-instance ] invalid-
packet [ interface interface-type interface-number | message-type { leave | query |
report } ] * command to check statistics about invalid Internet Group Management
Protocol (IGMP) packets saved on the switch.
– Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] invalid-
packet [ peer peer-address | message-type { keepalive | notification | sa-request |
sa-response | source-active } ] * command to check statistics about invalid MSDP
packets saved on the switch.
– Run the display pim [ vpn-instance vpn-instance-name | all-instance ] invalid-
packet [ interface interface-type interface-number | message-type { assert | bsr |
hello | join-prune | offer | backoff | win | pass } ] * command or display pim
[ vpn-instance vpn-instance-name | all-instance ] invalid-packet message-type
{ crp | register | register-stop } command to check statistics about invalid Protocol
Independent Multicast (PIM) packets saved on the switch.
l Run the following commands to check detailed information about a specified number of
latest invalid multicast protocol packets received by the switch:
– Run the display igmp invalid-packet [ packet-number ] verbose command to
check details information about a specified number of latest invalid IGMP packets
received by the switch.
– Run the display msdp invalid-packet [ packet-number ] verbose command to
check details information about a specified number of latest invalid MSDP packets
received by the switch.
– Run the display pim invalid-packet [ packet-number ] verbose command to check
details information about a specified number of latest invalid PIM packets received
by the switch.

5.10 Configuration Examples for IPv4 Multicast Route

Management
5.10.1 Example for Configuring a Multicast Static Route to

Change the RPF Route
In Figure 5-10, SwitchA, SwitchB, and SwitchC run Open Shortest Path First (OSPF) to
implement IP interworking, and their interfaces use Protocol Independent Multicast Sparse
Mode (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 load
on this link, multicast data needs to be transmitted along the path SwitchA -> SwitchC ->
SwitchB.
Figure 5-10 Configuring a static route to change the RPF route
SwitchC
10GE1/0/3 10GE1/0/2
VLANIF30 VLANIF40
10.12.1.2/24 10.13.1.2/24
10.12.1.1/24 10.13.1.1/24
VLANIF30 VLANIF40
10GE1/0/3 PIM-SM
10GE1/0/2
SwitchA SwitchB
10GE1/0/1 10GE1/0/1
VLANIF10 VLANIF10
10GE1/0/2 10.9.1.1/24 10.9.1.2/24 10GE1/0/3
VLANIF20 VLANIF50
10.8.1.1/24 10.7.1.1/24
10.8.1.2/24 10.7.1.2/24
Source Receiver

By configuring a multicast static route, you can change the reverse path forwarding (RPF)
interface used to receive multicast data, so that multicast and unicast services are transmitted
through different links to reduce load on a single link. 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 candidate bootstrap router (C-BSR) and candidate
rendezvous point (C-RP). Enable Internet Group Management Protocol (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. Multicast data can then 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. SwitchB is used as
an example in the following operations. Configurations of the other switches are similar.
# Create VLANs and add Layer 2 physical interfaces to the VLANs.
[~HUAWEI] sysname SwitchB
[*HUAWEI] commit
[~SwitchB] vlan batch 10 40 50
[*SwitchB] interface 10ge 1/0/1
[*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.

[*SwitchB-Vlanif10] ip address 10.9.1.2 24
[*SwitchB-Vlanif10] quit
[*SwitchB] commit
# Configure OSPF.
[~SwitchB] ospf
[*SwitchB-ospf-1] area 0
[*SwitchB-ospf-1-area-0.0.0.0] network 10.7.1.0 0.0.0.255


[*SwitchB-ospf-1-area-0.0.0.0] quit
[*SwitchB-ospf-1] 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 globally, PIM-SM on all Layer 3 interfaces, and 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-pim] c-bsr vlanif 30
[*SwitchC-pim] c-rp vlanif 30
[~SwitchC-pim] quit
# 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 originates from a unicast
routing protocol, and the RPF neighbor is SwitchA.
[~SwitchB] display multicast rpf-info 10.8.1.2
RPF information about source: 10.8.1.2
RPF interface: Vlanif10, RPF neighbor: 10.9.1.1
Referenced route/mask: 10.8.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 10.8.1.0 255.255.255.0 10.13.1.2
[*SwitchB] commit

# Run the display multicast rpf-info command on SwitchB to check the RPF route to
Source. The command output shows that the unicast RPF route has been replaced with 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 10.9.1.1 255.255.255.0
pim sm
#
interface Vlanif20
ip address 10.8.1.1 255.255.255.0
pim sm
#
interface Vlanif30
ip address 10.12.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.8.1.0 0.0.0.255
network 10.9.1.0 0.0.0.255
network 10.12.1.0 0.0.0.255
#
return

#
sysname SwitchB
#
vlan batch 10 40 50
#
#
interface Vlanif10
ip address 10.9.1.2 255.255.255.0
pim sm
#
interface Vlanif40
ip address 10.13.1.1 255.255.255.0
pim sm
#
interface Vlanif50
ip address 10.7.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 10.7.1.0 0.0.0.255
network 10.9.1.0 0.0.0.255
network 10.13.1.0 0.0.0.255
#
ip rpf-route-static 10.8.1.0 24 10.13.1.2
#
return

#
sysname SwitchC
#
vlan batch 30 40
#
#
interface Vlanif30
ip address 10.12.1.2 255.255.255.0
pim sm
#
interface Vlanif40
ip address 10.13.1.2 255.255.255.0
pim sm
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 10.12.1.0 0.0.0.255
network 10.13.1.0 0.0.0.255
#
pim
c-bsr Vlanif30
c-rp Vlanif30
#
return
5.10.2 Example for Configuring Multicast Static Routes to

Connect RPF Routes
In Figure 5-11, SwitchB and SwitchC run Open Shortest Path First (OSPF) to implement IP
interworking, but they have no unicast route to SwitchA. Switch interfaces must run Protocol
Independent Multicast Sparse Mode (PIM-SM) to provide multicast services. The receiver
host (Receiver) can receive data from Source1 and also needs to receive data from Source2.

Figure 5-11 Configuring multicast static routes to connect RPF routes
PIM-SM
OSPF
Source1
10.1.3.2/24
10.1.3.1/24
VLANIF13 10.1.4.1/24 10.1.4.2/24
10GE1/0/2 VLANIF40 VLANIF40 SwitchA
10GE1/0/3 10GE1/0/3
SwitchB
10GE1/0/1 10GE1/0/1
VLANIF20 VLANIF11
10.1.2.2/24 10.1.2.1/24 10.1.5.1/24
VLANIF20
10GE1/0/1
SwitchC
Source2
10GE1/0/2 10.1.5.2/24
VLANIF12
10.1.1.1/24
Receiver
A reverse path forwarding (RPF) route to Source2 can be established on the path SwitchC →
SwitchB → SwitchA by configuring multicast static routes on SwitchB and SwitchC. The
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. Multicast data can then be forwarded to Receiver along the multicast
distribution tree.
3. Configure multicast static routes to Source2 on SwitchB and SwitchC.

Procedure
Step 1 Configure IP addresses for interfaces and configure OSPF on each switch. SwitchB is used as
an example in the following operations. Configurations of the other switches are similar.
[~HUAWEI] sysname SwitchB
[*HUAWEI] commit
[~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.

[*SwitchB] commit
# Configure OSPF on SwitchB and SwitchC.

[~SwitchB] ospf
[*SwitchB-ospf-1] area 0
[*SwitchB-ospf-1-area-0.0.0.0] quit
[*SwitchB-ospf-1] 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.

[*SwitchC-Vlanif12] igmp enable
[*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:
Route selecting rule: preference-preferred
[~SwitchC] display multicast rpf-info 10.1.5.2

RPF information about source 10.1.5.2:
# Run the display pim routing-table command on SwitchC to check the PIM routing table.
SwitchC has multicast entries for Source2, indicating that Receiver can now receive multicast
data from Source2.
Total 1 (*, G) entry; 2 (S, G) entries

(*, 225.1.1.1)
RP: 10.1.2.2
UpTime: 03:54:19
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

#
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
#
#
pim
c-bsr Vlanif20
c-rp Vlanif20
#
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
#


#
return
5.10.3 Example for Configuring IPv4 Multicast Load Splitting
In Figure 5-12, SwitchE connects to HostA and has three equal-cost routes to the multicast
source (Source). According to the default reverse path forwarding (RPF) check policy,
SwitchE will select one of these equal-cost routes to transmit multicast data. When the rate of
multicast traffic is high, the network may become congested, lowering the quality of multicast
services. To ensure the quality of multicast services, multicast load splitting needs to be
configured so that multicast data can be transmitted through multiple equal-cost routes.
Figure 5-12 Networking diagram of multicast load splitting
PIM-SM
4 19
Source 1 .2/2 2.
1
8. 20 VL 68.
2 .16 NIF /0/1 10 A 4.1
A
19 VL E1 G NIF /2
G E1 6 4
10 SwitchB /0 0
24 /2 19
. 1 .1/ 2
8 0 VL .168
.16 IF2 /1 10 AN .4
10.110.1.2/24 192 AN 1/0 G IF .2/
VLANIF10 VL0GE 192.168.2.2/24 192.168.5.1/24
E1 6 24
/0 0
10GE1/0/4 1 VLANIF30 VLANIF80 /1
10GE1/0/2 10GE1/0/1 10GE1/0/2
VLANIF30 10GE1/0/2 SwitchE
192.168.2.1/24 VLANIF80
10 SwitchC 192.168.5.2/24 / 3 10GE1/0/4
SwitchA V G /0
19 LANE1/0 4 E1 1004 VLANIF140
2.1 IF /3 2 G F 10.110.2.2/24
68 40 1/ 10 ANI .2/2
.3. . 6. 100 L . 6
Loopback0 1/2 8 /2 V 68
16 IF /0 1
10.1.1.1/32 4
9 2. LAN E1 2.
1 1 V 0G 19
19 V 0GE 1
2.1 LA 1
68 NIF /0/
.3. 40 1 HostA
2/2
4
SwitchD
1. Configure IP addresses for interfaces on the switches.

2. Configure a unicast routing protocol, Intermediate System-Intermediate System (IS-IS)

in this example, to implement interworking among all switches and ensure that route
costs are the same.
3. Enable multicast routing on all switches and enable Protocol Independent Multicast
Sparse Mode (PIM-SM) on all 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. SwitchA is used as an example in the
following operations. Configurations of the other switches are similar.
[*HUAWEI] commit
[~SwitchA] vlan batch 10 20 30 40
[*SwitchA] commit
# Configure IP addresses and masks for Layer 3 interfaces.

[*SwitchA-LoopBack0] ip address 10.1.1.1 32
[*SwitchA] commit
Step 2 Configure IS-IS to implement interworking among all switches and ensure that route costs are
the same (SwitchA as an example).
[~SwitchA] isis
[*SwitchA-isis-1] network-entity 10.0000.0000.0001.00
[*SwitchA-isis-1] quit


[*SwitchA-Vlanif10] isis enable
[*SwitchA-LoopBack0] isis enable
[*SwitchA] commit
Step 3 Enable multicast routing on all switches and enable PIM-SM on all Layer 3 interfaces.
[*SwitchA] interface loopback 0
[*SwitchA-LoopBack0] pim sm
[*SwitchA] commit
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 VLANIF 140.
[~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. Brief information about the PIM routing table
on SwitchE is as follows:
[~SwitchE] display pim routing-table brief

Total 3 (*, G) entries, 3 (S, G) entries

Entries Upstream interface NDwnstrms
(*, 225.1.1.1) Vlanif100 1
(10.110.1.1, 225.1.1.1) Vlanif100 1
(*, 225.1.1.2) Vlanif80 1
(10.110.1.1, 225.1.1.2) Vlanif80 1
(*, 225.1.1.3) Vlanif60 1
(10.110.1.1, 225.1.1.3) Vlanif60 1
(*, G) and (S, G) entries are evenly distributed on the three equal-cost routes. The upstream
interfaces of the routes are VLANIF 100, VLANIF 80, and VLANIF 60, respectively.
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
pim sm
isis enable 1
#
interface Vlanif20
ip address 192.168.1.1 255.255.255.0
pim sm
isis enable 1
#
interface Vlanif30
ip address 192.168.2.1 255.255.255.0
pim sm
isis enable 1
#
interface Vlanif40
ip address 192.168.3.1 255.255.255.0
pim sm
isis enable 1
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
interface LoopBack0

ip address 10.1.1.1 255.255.255.255

pim sm
isis enable 1
#
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
pim sm
isis enable 1
#
interface Vlanif60
ip address 192.168.4.1 255.255.255.0
pim sm
isis enable 1
#
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
pim sm
isis enable 1
#
interface Vlanif80
ip address 192.168.5.1 255.255.255.0
pim sm
isis enable 1
#
interface 10GE1/0/1
#
interface 10GE1/0/2

#
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
pim sm
isis enable 1
#
interface Vlanif100
ip address 192.168.6.1 255.255.255.0
pim sm
isis enable 1
#
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
pim sm
isis enable 1
#
interface Vlanif80
ip address 192.168.5.2 255.255.255.0
pim sm
isis enable 1
#
interface Vlanif100
ip address 192.168.6.2 255.255.255.0
pim sm
isis enable 1
#
interface Vlanif140
ip address 10.110.2.2 255.255.255.0
pim sm
igmp static-group 225.1.1.1 inc-step-mask 0.0.0.1 number 3
isis enable 1
#
interface 10GE1/0/1

#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
return
5.11 Troubleshooting IPv4 Multicast Route Management
5.11.1 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 even though 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 configured correctly or does not match the network topology
because the topology has changed, the multicast routing table will not contain the routing
entry or 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 has been 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 has been 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
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

Configuration Guide - IP Multicast 6 IGMP Snooping Configuration
6 IGMP Snooping Configuration
This chapter describes how to configure IGMP snooping on a Layer 2 multicast device so that
the device can 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.
6.1 Overview of IGMP Snooping

6.2 Understanding IGMP Snooping
6.3 Application Scenarios for IGMP Snooping
6.4 Summary of IGMP Snooping Configuration Tasks
6.5 Licensing Requirements and Limitations for IGMP Snooping
6.6 Default Settings for IGMP Snooping
6.7 Configuring Basic IGMP Snooping Functions
6.8 Configuring IGMP Snooping Proxy
6.9 Configuring an IGMP Snooping Policy
6.10 Configuring IGMP Snooping Membership Fast-Update
6.11 Configuring IGMP Snooping SSM Mapping
6.12 Maintaining IGMP Snooping
6.13 Configuration Examples for IGMP Snooping
6.14 Troubleshooting IGMP Snooping
6.1 Overview of IGMP Snooping
Definition
Internet Group Management Protocol Snooping (IGMP snooping) is a Layer 2 IPv4 multicast
protocol. The IGMP snooping protocol maintains information about the outbound 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.
Purpose
In most cases, particularly in a LAN, multicast packets have to pass through Layer 2 devices.
As shown in Figure 6-1, multicast packets have to pass through a Layer 2 switch located
between multicast users and the Layer 3 multicast device, Router.
Figure 6-1 IGMP snooping networking
Source
PIM
network
Router
Switch
HostA HostC
Receiver Receiver
After receiving multicast packets from Router, Switch forwards multicast packets to the
multicast receivers. The destination address of multicast packets is a multicast group address.
Switch cannot learn multicast MAC address entries, so it broadcasts multicast packets in the
broadcast domain. All hosts in the broadcast domain will receive the multicast packets,
regardless of whether they are members of the multicast group. This wastes network
bandwidth and threatens network security.
IGMP snooping solves this problem. After IGMP snooping is configured, the Layer 2
multicast device can snoop and analyze IGMP messages between multicast users and the
upstream router. The Layer 2 multicast device sets up Layer 2 multicast forwarding entries to
control forwarding of multicast data. In this way, multicast data is not broadcast on the Layer
2 network.
6.2 Understanding IGMP Snooping
6.2.1 IGMP Snooping

Fundamentals
IGMP snooping is a basic Layer 2 multicast function that forwards and controls multicast
traffic at Layer 2. IGMP snooping runs on a Layer 2 multicast device and analyzes IGMP
messages exchanged between a Layer 3 device and hosts to set up and maintain a Layer 2
multicast forwarding table. The Layer 2 multicast device forwards multicast packets based on
the Layer 2 multicast forwarding table.
As shown in Figure 6-2, after receiving multicast packets from a Layer 3 device Router,
Switch at the edge of the access layer forwards the multicast packets to receiver hosts. If
Switch does not run IGMP snooping, it broadcasts multicast packets at Layer 2. After IGMP
snooping is configured, Switch forwards multicast packets only to specified hosts.
With IGMP snooping configured, Switch listens on IGMP messages exchanged between
Router and hosts. It analyzes packet information (such as packet type, group address, and
receiving interface) to set up and maintain a Layer 2 multicast forwarding table, and forwards
multicast packets based on the Layer 2 multicast forwarding table.
Figure 6-2 Multicast packet transmission before and after IGMP snooping is configured on a
Layer 2 multicast device
Multicast packet transmission Multicast packet transmission

without IGMP Snooping when IGMP Snooping runs
Source Source
PIM Router PIM

Router
network network
Switch IGMP Switch

Snooping
HostA HostC HostA HostC

Receiver HostB Receiver HostB Receiver
Receiver
Multicast Packet
Concepts
As shown in Figure 6-3, Router (Layer 3 device) receives multicast data from the multicast
source and forwards the data to downstream devices. IGMP snooping is configured on
SwitchA and SwitchB. HostA, HostB, and HostC are receiver hosts.

Figure 6-3 IGMP snooping ports

Source
PIM Router
network
SwitchA SwitchB
HostA HostB HostC HostD

Receiver Receiver Receiver
Router port
Member port
Multicast Packet
Figure 6-3 shows IGMP snooping ports. The following table describes these ports.
Table 6-1 IGMP snooping ports

Port Role Function Generation
Router port A router port receives l A dynamic router port is

Ports marked as blue points multicast packets from a generated by IGMP
on SwitchA and SwitchB. Layer 3 multicast device snooping. A port
such as a designated router becomes a dynamic
NOTE
A router port is a port on a
(DR) or IGMP querier. router port when it
Layer 2 multicast device and receives an IGMP
connects to an upstream General Query message
multicast router. "Router port" or PIM Hello message
mentioned in this document with any source address
does not refer to a port on a except 0.0.0.0. The PIM
router.
Hello messages are sent
from the PIM port on a
to discover and maintain
neighbor relationships.
l A static router port is
manually configured.

Port Role Function Generation
Member port A member port is a user-side l A dynamic member port

Ports marked as green points port connecting to group is generated by IGMP
on SwitchA and SwitchB. members. A Layer 2 snooping. A Layer 2
multicast device sends multicast device sets a
multicast data to the receiver port as a dynamic
hosts through member ports. member port when the
port receives an IGMP
Report message.
l A static member port is
manually configured.
A router port and a member port are outbound interfaces in Layer 2 multicast forwarding
entries. A router port functions as an upstream interface, whereas a member port functions as
a downstream interface. Port information learned through protocol packets is saved as
dynamic entries, and port information manually configured is saved as static entries.
Besides the outbound interfaces, each entry includes multicast group addresses and VLAN
IDs.
l Multicast group addresses can be multicast IP addresses or multicast MAC addresses
mapped from multicast IP addresses. In MAC address-based forwarding mode, multicast
data may be forwarded to hosts that do not require the data because multiple IP addresses
are mapped to the same MAC address. The IP address-based forwarding mode can
prevent this problem.
l The VLAN ID specifies a Layer 2 broadcast domain. After multicast VLAN is
configured, the inbound VLAN ID is the multicast VLAN ID, and the outbound VLAN
ID is a user VLAN ID. If multicast VLAN is not configured, both the inbound and
outbound VLAN IDs are the ID of the VLAN to which a host belongs. For details about
multicast VLAN, see 8.2 Understanding Multicast VLAN Replication.
Implementation
After IGMP snooping is configured, the Layer 2 multicast device processes the received
IGMP protocol packets in different ways and sets up Layer 2 multicast forwarding entries.

Table 6-2 IGMP message processing by IGMP snooping

IGMP Working Phase IGMP Message Received Processing Method
on a Layer 2 Device
General query IGMP General Query A Layer 2 multicast device

The IGMP querier message forwards IGMP General
periodically sends General Query messages to all ports
Query messages (with excluding the port receiving
destination address the messages in a VLAN.
224.0.0.1) to all hosts and The Layer 2 multicast
routers on the local network device processes the
segment, to check which receiving port as follows:
multicast groups have l If the port is not in the
members on the network router port list, the Layer
segment. 2 multicast device adds it
to the list and starts the
aging timer.
l If the port is included in
the router port list, the
resets the aging timer of
the router port.
NOTE
By default, the Layer 2
multicast device sets the aging
time to 180 seconds when the
router port receives an IGMP
General Query message. You
can set the aging time using a
command.


on a Layer 2 Device
Membership report IGMP Report message A Layer 2 multicast device

Membership Report forwards an IGMP Report
messages are used in two message to all router ports
scenarios: in a VLAN. The Layer 2
multicast device obtains the
l Upon receiving an IGMP multicast group address
General Query message, from the Report message
a member returns an and performs the following
IGMP Report message. operations on the port
l A member sends an receiving the message:
IGMP Report message to l If the multicast group
the IGMP querier to matches no forwarding
announce its joining to a entry, the Layer 2
multicast group. multicast device creates
a forwarding entry, adds
the port to the outbound
interface list as a
dynamic member port,
and starts the aging
timer.
l If the multicast group
matches a forwarding
entry but the port is not
in the outbound interface
list, the Layer 2 multicast
device adds the port to
the outbound interface
list as a dynamic member
port, and starts the aging
timer.
l If the multicast group
entry and the port is in
the router port list, the
resets the aging timer.
NOTE
After a group member port
receives an IGMP Report
message, its aging time is
calculated using the following
formula:
Aging time = Robustness
variable x General query
interval + Maximum response
time for General Query
messages


on a Layer 2 Device
Leave of multicast members IGMP Leave message The Layer 2 multicast

There are two phases: device determines whether
the multicast group matches
1. An IGMPv2/IGMPv3 a forwarding entry and
member sends an IGMP whether the port that
Leave message to notify receives the message is in
the IGMP querier on the the outbound interface list.
local network segment
that it has left a multicast l If no forwarding entry
group. matches the multicast
group or the outbound
2. Upon receiving the interface list of the
IGMP Leave message, matching entry does not
the IGMP querier obtains contain the receiving
the multicast group port, the Layer 2
address and sends an multicast device drops
IGMP Group-Specific/ the IGMP Leave
Group-Source-Specific message.
Query message to the
multicast group. l If the multicast group
entry and the port is in
the outbound interface
list, the Layer 2 multicast
device forwards the
IGMP Leave message to
all router ports in the
VLAN.
The following assumes that
the port receiving an IGMP
Leave message is a dynamic
member port. Within the
aging time of the member
port:
l If the port receives
IGMP Report messages
in response to the IGMP
Group-Specific/Group-
Source-Specific Query
message, the Layer 2
multicast device knows
that the multicast group
has members connected
to the port and resets the
aging timer.
l If the port receives no
IGMP Report message in
response to the IGMP
Group-Specific/Group-
Source-Specific Query


on a Layer 2 Device
message, no member of
the multicast group
exists under the
interface. Then the Layer
2 multicast device
deletes the port from the
outbound interface list
when the aging time is
reached.
NOTE
After a group member port
receives an IGMP Leave
message, its aging time is
calculated using the following
formula:
Aging time = Robustness
variable x Group-Specific
query interval
IGMP Group-Specific/ An IGMP Group-Specific/

Group-Source-Specific Group-Source-Specific
Query message Query message is forwarded
to all ports in a VLAN
excluding the port receiving
the message.
Upon receiving a PIM Hello message, a Layer 2 multicast device forwards the message to all
ports excluding the port that receives the Hello message. The Layer 2 multicast device
processes the receiving port as follows:
l If the port is included in the router port list, the Layer 2 multicast device resets the aging
timer of the router port.
l If the port is not in the router port list, the Layer 2 multicast device adds it to the list and
starts the aging timer.
When the Layer 2 multicast device receives a PIM Hello message, it sets the aging time of the router
port to the Holdtime value in the Hello message.
If a static router port is configured, the Layer 2 multicast device forwards received IGMP
Report and Leave messages to the static router port. If a static member port is configured for a
multicast group, the Layer 2 multicast device adds the port to the outbound interface list for
the multicast group.
After a Layer 2 multicast forwarding table is set up, the Layer 2 multicast device searches the
multicast forwarding table for outbound interfaces of multicast data packets according to the
VLAN IDs and destination addresses (group addresses) of the packets. If outbound interfaces
are found for a packet, the Layer 2 multicast device forwards the packet to the matching
member ports and router ports. If no outbound interface is found, the Layer 2 multicast device
drops the packet or broadcasts the packet in the VLAN.

6.2.2 IGMP Snooping SSM Mapping

Compared to Any-Source Multicast (ASM), Source-Specific Multicast (SSM) conserves
multicast addresses and has higher security. Only IGMPv3 supports SSM. A host running
IGMPv3 can specify multicast source addresses in IGMP Report messages. Some hosts can
run only IGMPv1 or IGMPv2. To enable such hosts to obtain the SSM service, multicast
devices need to provide the IGMP Snooping SSM mapping function.
IGMP snooping SSM mapping is Layer 2 SSM mapping on an IPv4 multicast network. After
static SSM mapping entries are configured on a multicast device, the device can convert (*,
G) information in IGMPv1 and IGMPv2 Report messages to (S, G) information to provide the
SSM service for IGMPv1 and IGMPv2 hosts. S indicates the multicast source, G indicates the
multicast group, and the asterisk (*) indicates any multicast source. By default, SSM group
addresses range from 232.0.0.0 to 232.255.255.255. You can configure an SSM group policy
to change the address range of SSM groups.
As shown in Figure 6-4, HostA runs IGMPv3, HostB runs IGMPv2, and HostC runs
IGMPv1. HostB and HostC cannot run IGMPv3. To provide the SSM service for all the hosts
on the network segment, configure IGMP Snooping SSM mapping on Switch.
Figure 6-4 Networking diagram of IGMP Snooping SSM mapping
port HostA (IGMPv3)

3 Re
MPv Receiver
IG
IGMPv2 Report
Router
for 232.1.2.2
PIM network HostB (IGMPv2)
Switch Receiver
IGM
for Pv1
23 Re
2.1 po
.1. rt HostC (IGMPv1)
1
Receiver
The following table lists the SSM mapping entries configured on Switch.
Multicast Group Address Mapping Multicast Source Address
232.1.1.0/24 10.10.1.1
232.1.2.0/24 10.10.2.2
232.1.3.0/24 10.10.3.3

When Switch receives Report messages from HostB and HostC, it checks whether the
multicast group addresses in the messages are within the SSM group address range. If so,
Switch generates (S, G) entries based on the SSM mappings, as shown in the following table.
Multicast Group Address in IGMPv1/ Generated Multicast Forwarding Entry

IGMPv2 Report
232.1.1.1 (from HostC) (10.10.1.1, 232.1.1.1)
232.1.2.2 (from HostB) (10.10.2.2, 232.1.2.2)
When the multicast group address in a Report message is within the SSM group address
range, but Switch no SSM mapping entry matching the multicast group address, it does not
provide the SSM service and drops the Report message.
If the multicast group address in a Report message is out of the SSM group address range,
Switch provides only the ASM service.
6.2.3 IGMP Snooping Proxy
Fundamentals
To reduce the number of IGMP messages transmitted on the network segments of user hosts,
you can configure IGMP snooping proxy on a Layer 2 multicast device. Then the Layer 2
multicast device substitutes the upstream Layer 3 device to send IGMP Query messages to
user hosts, and substitutes user hosts to send Report messages to the Layer 3 device. A device
configured with IGMP snooping proxy functions as a host for its upstream device and a
querier for its downstream hosts.
As shown in Figure 6-5, when Switch runs IGMP snooping, it transparently forwards IGMP
Query messages to the hosts, and Report/Leave messages to the upstream Router. When
numerous hosts exist on the network, redundant IGMP messages increase the burden of
Router.
With IGMP snooping proxy configured, Switch can terminate IGMP Query messages sent
from Router and IGMP Report/Leave messages sent from downstream hosts. When receiving
these messages, Switch constructs new messages to send them to Router or hosts.

Figure 6-5 Networking diagram of IGMP snooping proxy
Before IGMP snooping proxy is After IGMP snooping proxy is

enabled enabled
Source Source
PIM Router PIM

Router
network network
IGMP IGMP
Querier Querier
IGMP Switch IGMP Snooping Switch
Snooping Proxy
HostA HostC HostA HostC

Receiver HostB Receiver HostB Receiver
Receiver
Report/Leave from Host Report/Leave from Switch

Query from Router Query from Switch
After IGMP snooping proxy is deployed on the Layer 2 device, the Layer 3 device considers
that it interacts with only one user. The Layer 2 device interacts with the upstream device and
downstream hosts. The IGMP snooping proxy function conserves bandwidth by reducing
IGMP message exchanges. In addition, IGMP snooping proxy functions as a querier to
process protocol messages received from downstream hosts and maintain group memberships.
This reduces the load of the upstream Layer 3 device.
Implementation
A device that runs IGMP snooping proxy sets up and maintains a Layer 2 multicast
forwarding table and sends multicast data to hosts based on the multicast forwarding table.
Table 6-3 describes how the IGMP snooping proxy device processes IGMP messages.

Table 6-3 received IGMP message processing by IGMP snooping proxy

IGMP Message Processing Method
IGMP General Query message The Layer 2 device sends the IGMP General
Query message to all ports excluding the
port receiving the message in a VLAN. The
device generates an IGMP Report message
based on the group memberships and sends
the IGMP Report message to all router
ports.
IGMP Group-Specific/Group-Source- If the group specified in the message has

Specific Query message member ports in the multicast forwarding
table, the Layer 2 device responds with an
IGMP Report message to all router ports.
IGMP Report message l If the multicast group matches no

forwarding entry, the Layer 2 device
creates a forwarding entry, adds the
message receiving port to the outbound
interface list as a dynamic member port,
starts the aging timer, and sends an
IGMP Report message to all router
ports.
l If the multicast group matches a
forwarding entry and the message
receiving port is in the outbound
interface list, the device resets the aging
timer.
l If the multicast group matches a
forwarding entry, but the port is not in
the outbound interface list, the Layer 2
device adds the port to the list as a
dynamic router port, and starts the aging
timer.
IGMP Leave message The Layer 2 device sends a Group-Specific

Query message to the port that receives the
IGMP Leave message. The Layer 2 device
sends an IGMP Leave message to all router
ports only when the last member port is
deleted from the forwarding entry.
6.3 Application Scenarios for IGMP Snooping
6.3.1 IGMP Snooping Application

Networking Description
As shown in Figure 6-6, multiple multicast sources such as Source1 and Source2 exist on a
PIM network. The sources provide multicast video services for users on the LAN. Some users
such as HostA and HostC on the LAN want to receive video data in multicast mode. To
prevent multicast data from being broadcast on the LAN, configure IGMP snooping on Layer
2 multicast device to accurately forward multicast data on the Layer 2 network, which
prevents bandwidth waste and network information leakage.
Figure 6-6 IGMP snooping networking

Source1 Source2
PIM
network
Router
Switch
HostA HostC
Receiver HostB Receiver
Multicast Packet
Deployed Features
You can deploy the following features to accurately forward multicast data on the network
shown in Figure 6-6:
l PIM and IGMP on the Layer 3 multicast device Router to route multicast data to user
segments.
l IGMP snooping on the Layer 2 device Switch so that Switch can set up and maintain a
Layer 2 multicast forwarding table to forward multicast data to specified users.
l IGMP snooping proxy after configuring IGMP snooping on Switch to release Router
from processing a large number of IGMP messages.
l IGMP snooping SSM mapping on Switch when receiver hosts running IGMPv1 or
IGMPv2 want to use SSM.
6.4 Summary of IGMP Snooping Configuration Tasks

Table 6-4 lists IGMP snooping configuration tasks.
Table 6-4 IGMP snooping configuration tasks

Task Description
6.7 Configuring Basic IGMP Snooping When multicast data is forwarded to a Layer
Functions 2 multicast device connected to a user
network segment, configure IGMP snooping
on the Layer 2 multicast device to prevent
multicast data from being flooded in the
broadcast domain and to accurately forward
multicast data at Layer 2. After IGMP
snooping is configured, the Layer 2
multicast device can snoop and analyze
IGMP messages between multicast users
and the upstream router. The Layer 2
multicast device sets up Layer 2 multicast
forwarding entries to control forwarding of
multicast data. In this way, multicast data is
not broadcast on the Layer 2 network.
6.8 Configuring IGMP Snooping Proxy You can configure the IGMP snooping
proxy function on a Layer 2 multicast
device in either of the following situations:
l IGMP is not enabled on a Layer 3
multicast device (for example, static
multicast groups are configured), and no
IGMP querier is available on the
network to maintain multicast
membership. After IGMP snooping
proxy is configured on a Layer 2
multicast device, the device functions as
the IGMP querier to send Query
messages to receiver hosts.
l IGMP is enabled on a Layer 3 multicast
device. To reduce the number of IGMP
Report/Leave messages transmitted
between the Layer 3 multicast device
and network segments of receiver hosts,
configure IGMP snooping proxy on the
Layer 2 multicast device between the
Layer 3 multicast device and receiver
hosts. The Layer 2 multicast device
forwards IGMP Report or Leave
messages from receiver hosts to the
upstream device and sends Query
messages from the upstream device to
receiver hosts.

Task Description
6.9 Configuring an IGMP Snooping To filter out multicast messages on a Layer

Policy 2 multicast device or limit the range of
multicast groups that hosts can join,
configure an IGMP snooping policy on the
Layer 2 multicast device.
6.10 Configuring IGMP Snooping To improve running efficiency of multicast

Membership Fast-Update services and user experience, configure
quick membership update on a Layer 2
multicast device so that the Layer 2
multicast device quickly updates entries
when receiver hosts join or leave a multicast
group.
6.11 Configuring IGMP Snooping SSM On a Layer 2 network, some receiver hosts
Mapping can only run IGMPv1 or IGMPv2. To allow
these hosts to use SSM, configure IGMP
snooping SSM mapping on the Layer 2
multicast device.

Snooping
a multicast source.

IGMP snooping is a basic software function of the switch. The license for basic software
functions has been loaded and activated before delivery. You do not need to manually activate
it.
Table 6-5 Products and minimum versions supporting IGMP snooping in a VLAN
Required
CE5810EI V100R002C00
CE5850EI V100R001C00
CE5850HI V100R003C00
CE5855EI V100R005C10
CE5880EI V200R005C10
CE6810-48S4Q-LI/CE6810-48S-LI V100R003C10
CE6810-32T16S4Q-LI/CE6810-24S2Q-LI V100R005C10
CE6810EI V100R003C00
CE6850EI V100R001C00
CE6850-48S6Q-HI V100R005C00
CE6855HI V200R001C00
CE6856HI V200R002C50
CE6857EI V200R005C10
CE6860EI V200R002C50
CE6865EI V200R005C00
CE6870-48T6CQ-EI V200R002C50
CE6875EI V200R003C00
CE6880EI V200R002C50
CE6881/CE6820/CE6863 V200R005C20
CE7850EI V100R003C00


Required
CE7855EI V200R001C00
CE8850-32CQ-EI V200R002C50
CE8850-64CQ-EI V200R005C00
CE8860EI V100R006C00
CE8861EI/CE8868EI V200R005C10
Feature Limitations
l 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.
l After PIM-DM is enabled on a VLANIF interface, IGMP snooping cannot be enabled in
the corresponding VLAN. Similarly, after IGMP snooping is enabled in a VLAN, PIM-
DM cannot be enabled on the corresponding VLANIF interface.
l In the scenario when both Layer 2 and Layer 3 multicast are enabled, that is, when Layer
2 multicast is configured in a VLAN and Layer 3 multicast is configured on the
corresponding VLANIF interface, the following functions must be configured
simultaneously to ensure normal on-demand forwarding of multicast traffic:
– IGMP snooping must be enabled in a VLAN.
– PIM (PIM-SM or Bidir-PIM) and IGMP must be enabled on the corresponding
VLANIF interface.
l The CE6810LI does not support the following configurations: setting the IGMP
snooping version to V3 and enabling fast leave for member ports.
l When configuring the multicast data forwarding mode (IP address-based or MAC
address-based) in a VLAN, pay attention to the following points:
– 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.
– If the VLAN is configured as a customer edge (CE) VLAN of Transparent
Interconnection of Lots of Links (TRILL) and enabled with IGMP snooping, the
multicast packets in the VLAN are forwarded based on MAC addresses, and the
forwarding mode cannot be changed.
– Multiple IPv4 multicast addresses may be mapped to the same IPv4 multicast MAC
address according to the multicast IP-and-MAC address mapping mechanism.
When the MAC address-based multicast forwarding mode is used in a VLAN and a
group IP address for receivers and the multicast IP address reserved for a protocol
are mapped to the same IP multicast MAC address, the protocol cannot run
normally. For example, IP multicast address 224.0.0.5 is reserved for the OSPF
protocol. If a multicast group uses IP multicast address 225.0.0.5, the two IP
multicast addresses are both mapped to IP multicast MAC address
01-00-5E-00-00-05. In this case, the OSPF protocol cannot run normally. Make an
appropriate IP multicast address plan to prevent this problem.

– When the MAC address-based multicast forwarding mode is used in a VLAN, the
IGMP snooping version cannot be set to v3.
– When MAC address-based multicast forwarding is configured in a VLAN,
multicast forwarding entry creation cannot be triggered by data traffic, but is
triggered upon receiving user requests. If no user orders a program, multicast traffic
is broadcast in the VLAN by default.
l If Layer 3 multicast functions (such as IGMP and PIM) are enabled on a VLANIF
interface, the corresponding VLAN does not support configuration of an IGMP snooping
querier, Report and Leave message suppression, or IGMP snooping proxy. Similarly, if
any of the preceding functions is made in a VLAN, Layer 3 multicast functions cannot
be enabled on the corresponding VLANIF interface.
l If a multicast network already has an IGMP querier, it is not recommended to configure
an IGMP snooping querier, because the configuration will cause re-election of the IGMP
querier. If you configure an IGMP snooping querier on a switch, ensure that the source
IP address of the General Query messages sent from the switch is larger than the IP
address of the upstream IGMP querier.
l When configuring IGMP snooping on an M-LAG, ensure that the IGMP snooping
querier or IGMP snooping proxy configuration is consistent on the M-LAG master and
backup devices.
l The following pairs of functions cannot be configured in the same VLAN:
– IGMP snooping querier and IGMP snooping proxy
– Report and Leave message suppression and IGMP snooping proxy
l IGMP snooping cannot be used with VLAN mapping.
6.6 Default Settings for IGMP Snooping
Table 6-6 Default settings for IGMP snooping
IGMP snooping Disabled
IGMP snooping version Version 2 (IGMP snooping can process

IGMPv1 and IGMPv2 messages in a
VLAN)
IGMP snooping interface learning Enabled when IGMP snooping is enabled
IGMP snooping querier Disabled
IGMP snooping general query interval 60s
IGMP snooping message suppression Disabled
IGMP snooping proxy Disabled
IGMP snooping SSM mapping Disabled

Configuring basic IGMP snooping functions enables the switch to create and maintain a
Layer 2 multicast forwarding table, based on which multicast data packets can be forwarded
accurately to receivers at the data link layer.
Before configuring IGMP snooping functions, create the VLAN.
6.7.1 Enabling IGMP Snooping and 6.7.2 Configuring the IGMP Snooping Version are
mandatory and other tasks are optional.
6.7.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 2 Run igmp snooping enable
IGMP snooping is enabled globally.
Step 3 Run vlan vlan-id
The VLAN view is displayed.
Step 4 (Optional) Run multicast layer-2 forwarding-mode { ip | mac }
The multicast forwarding mode in the VLAN is set to IP address-based or MAC address-
based forwarding.
By default, the CE6810LI forwards multicast flows based on MAC addresses, and the other
models forward multicast flows based on IP addresses.

l On the CE6810LI, the default multicast forwarding mode cannot be changed using this command.
l Configure the multicast forwarding mode in a VLAN before IGMP snooping is enabled in the
VLAN. Then enable IGMP snooping in the VLAN for the configuration to take effect.
l If the device forwards multicast data packets based on MAC addresses, do not use a group address
on the network if the group address maps to the same multicast MAC address as a multicast IP
address reserved for a protocol. Otherwise, the protocol that uses the multicast IP address cannot run
normally. For example, Open Shortest Path First (OSPF) uses 224.0.0.5 to send protocol packets.
This multicast IP address maps to multicast MAC address 01-00-5E-00-00-05. If multicast data
packets are forwarded based on MAC addresses and use multicast IP address 225.0.0.5 (also
mapping to 01-00-5E-00-00-05), the OSPF protocol cannot run normally.
l If the VLAN is configured as a customer edge (CE) VLAN of Transparent Interconnection of Lots
of Links (TRILL) and enabled with IGMP snooping, the multicast packets in the VLAN are
forwarded based on MAC addresses, and the forwarding mode cannot be changed.

IGMP snooping is enabled in the VLAN.
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
6.7.2 Configuring the IGMP Snooping Version
Context
Internet Group Management Protocol (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 on the Layer 2 device should be the same as that 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 the same IGMP version. When hosts that run different
IGMP versions exist in a VLAN, set an appropriate IGMP snooping version to enable the
switch to process IGMP messages of different versions.
By default, when IGMP snooping V3 is configured on a switch, the switch processes received
IGMPv3 messages based on the mechanism in the simplified version of IGMPv3 (lightweight
IGMPv3).
l The differences between lightweight IGMPv3 and standard IGMPv3 are as follows:
– When a switch receives a message whose type is MODE_IS_INCLUDE,
ALLOW_NEW_SOURCES, or BLOCK_OLD_SOURCES and whose group
address is in the ASM address range, lightweight IGMPv3 discards the message
without processing it, whereas standard IGMPv3 processes the message normally.
– When a switch receives a message whose type is MODE_IS_EXCLUDE,
CHANGE_TO_EXCLUDE_MODE, or CHANGE_TO_INCLUDE_MODE and

whose group address is in the ASM address range, if the number of source
addresses is not 0, lightweight IGMPv3 processes the message in the same way as
when the number of source addresses is 0, whereas standard IGMPv3 processes the
message normally.
– When a switch receives a message whose type is MODE_IS_EXCLUDE or
CHANGE_TO_EXCLUDE_MODE and whose group address is in the SSM
address range, if the number of source addresses is not 0, lightweight IGMPv3 maps
multicast sources to multicast groups based on the SSM mapping configuration on
the switch. If the mapping fails, the switch does not process the message. Standard
IGMPv3 processes the message based on the mappings between the multicast
sources and multicast groups in the message.
l Lightweight IGMPv3 and standard IGMPv3 process received messages in the same way
in the following cases:
– The type of the received message is MODE_IS_INCLUDE,
CHANGE_TO_INCLUDE_MODE, ALLOW_NEW_SOURCES, or
BLOCK_OLD_SOURCES and the group address is in the SSM address range
– The type of the received message is MODE_IS_EXCLUDE or
CHANGE_TO_EXCLUDE_MODE, the group address is in the SSM address
range, and the number of source addresses is 0
– The type of the received message is MODE_IS_EXCLUDE,
CHANGE_TO_EXCLUDE_MODE or CHANGE_TO_INCLUDE_MODE, the
group address is in the ASM address range, and the number of source addresses is 0
You can run the igmp snooping version 3 standard-full command to configure standard
IGMP snooping V3.
Procedure
Step 3 Run igmp snooping version version
The version of IGMP messages that the switch can process is set.
By default, the switch can process IGMPv1 and IGMPv2 messages but cannot process
IGMPv3 messages.
The CE6810LI does not support IGMP snooping V3.

When MAC address-based forwarding is enabled in the VLAN, IGMPv3 cannot be configured.
Step 4 (Optional) Run igmp snooping version 3 standard-full
Standard IGMP snooping V3 is configured.
By default, when IGMP snooping V3 is configured on a switch, the switch processes received
IGMPv3 messages based on the mechanism in lightweight IGMPv3.

The CE6880EI, CE6810LI, and CE5880EI do not support this function.
Step 5 Run commit

----End
6.7.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 2 (Optional) Configure disabling of dynamic learning of router ports.
1. Run vlan vlan-id
2. Run igmp snooping router-learning disable
Dynamic router port learning is disabled.
By default, dynamic router port learning is enabled in a VLAN.
3. Run quit
Exit from the VLAN view.
Step 4 Run igmp snooping static-router-port vlan { vlan-id1 [ to vlan-id2 ] } &<1-10>
An interface is configured as a static router port.

Step 5 Run commit
----End
6.7.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 an aging time.
If the hosts connected to an interface need to receive the multicast data of a specific multicast
group or sent from a source to a group for a long time, add the interface statically to the group
or source-group. The manually added interface is a static member port. Static member ports
will not age out.
Procedure
Step 3 (Optional) 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
----End

6.7.5 (Optional) Configuring an IGMP Snooping Querier
Context
When IGMP snooping is enabled on a Layer 2 device, the Layer 2 device can listen to 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 to IGMP
protocol packets in the following conditions, even when IGMP snooping is enabled:
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 sends IGMP Query messages to
user hosts in place of the upstream Layer 3 multicast device.
Procedure
Step 3 Run igmp snooping querier enable
The IGMP snooping querier function is enabled.
l The IGMP snooping querier function cannot be enabled in a VLAN if the corresponding Layer 3
VLANIF interface has Layer 3 multicast functions (such as IGMP and PIM) enabled.
l After an IGMP snooping querier is enabled, the switch periodically broadcasts IGMP Query
messages to all the interfaces in the VLAN, including the router ports. 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. If
you configure an IGMP snooping querier on a switch, ensure that the source IP address of the
General Query messages sent from the switch is larger than the IP address of the upstream IGMP
querier.
l IGMP snooping querier and IGMP snooping proxy cannot be enabled in the same VLAN.
Step 4 (Optional) Run igmp snooping querier-election
The querier election function is enabled.
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.

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 Configuration Description Default Version

Parameter Command Setting
Interval for igmp snooping The querier 60 seconds IGMPv1,

sending IGMP query interval sends IGMP The default IGMPv2,
General Query query-interval General Query general query IGMPv3
messages messages at the interval is 60
specified seconds, which
interval to is different than
maintain the default
memberships of value 125
interfaces in a seconds defined
VLAN. by RFC
documents. A
Huawei querier
and a non-
Huawei querier
must send
IGMP general
query messages
at the same
interval.


IGMP igmp snooping The robustness 2 IGMPv1,

robustness robust-count variable defines IGMPv2,
variable robust-count the following IGMPv3
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.


Maximum igmp snooping When receiving 10 seconds IGMPv2,

response time query max- IGMP Report IGMPv3
for IGMP response-time messages from
Query messages max-response- hosts, the
time 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.


Interval for igmp snooping When receiving 1 second IGMPv2,

sending IGMP query last- IGMP Leave IGMPv3
Group-Specific member- messages from
Query messages interval last- a host, the
member- switch
interval 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.
Step 6 Run quit
Step 7 (Optional) Run 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 another device on the network,
use this command to set another IP address.
Step 8 Run commit
----End
6.7.6 (Optional) Suppressing Report and Leave Messages

Context
IGMP periodically sends Query and Response messages to maintain group memberships.
When multiple members join the same group, they send a large number of duplicate Report
messages to the IGMP router. When IGMPv2 or IGMPv3 hosts leave a multicast group, they
send a large number of duplicate Leave messages. To conserve bandwidth, configure
suppression of 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. The
switch sends a Leave message only when the last member leaves the multicast group.
Procedure
Step 3 Run igmp snooping report-suppress
The Report and Leave messages are suppressed.
When configuring message suppression, pay attention to the following points:

l After message suppression is configured in a VLAN, Layer 3 multicast functions (such as IGMP and
PIM) 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
6.7.7 (Optional) Configuring the IPv4 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.
Procedure

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
6.7.8 (Optional) Disabling Users from Dynamically Joining

Multicast Groups
Context
If an upstream Layer 3 multicast device is a non-Huawei device and has static multicast
groups configured on the user-side interface, multicast users are not allowed to dynamically
join or leave multicast groups. In this case, disable the switch from sending IGMP Report and
Leave messages carrying static group addresses to the upstream device.
Procedure
Step 3 Run igmp snooping static-group suppress-dynamic-join
The switch is disabled from sending IGMP Report and Leave messages that contain static
group addresses to the upstream device.
By default, the switch forwards IGMP Report and Leave messages that contain static group
addresses to the router port.
Step 4 Run commit
----End
6.7.9 Verifying the Basic IGMP Snooping Function Configuration

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
6.8 Configuring IGMP Snooping Proxy
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 group memberships. In this
case, configure the IGMP snooping proxy function on a Layer 2 device so that the device
functions as an IGMP querier to send IGMP Query messages.
When IGMP is enabled, IGMP snooping proxy can be deployed on a Layer 2 device to allow
the device to send IGMP Report messages to the upstream device in place of user hosts. In
this case, the Layer 3 device receives fewer IGMP Report and Leave messages.
IGMP snooping proxy enables the switch to send IGMP Query messages to user hosts in
place of the Layer 3 device and send IGMP Report/Leave messages to the Layer 3 device in
place of user hosts. That is, The switch functions as a host for the upstream device and a
querier for its downstream device. This function saves bandwidth between the upstream
device and switch.
Procedure


Step 3 Run igmp snooping proxy
IGMP snooping proxy is enabled.
l IGMP snooping proxy cannot be enabled in a VLAN if the corresponding VLANIF interface has
Layer 3 multicast function (such as IGMP and PIM) 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 6.7.5 (Optional) Configuring an IGMP Snooping Querier and 6.7.6
(Optional) Suppressing Report and Leave Messages.
Step 4 (Optional) Run igmp snooping proxy router-protocol-pass

The switch is configured to transparently transmit IGMP messages in the VLAN.
By default, the switch with IGMP snooping proxy enabled terminates IGMP messages it
receives and learns multicast forwarding entries from the packets. If IGMP snooping proxy is
enabled on both the upstream device and switch, you can run this command to enable the
switch 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 5 (Optional) Run quit
Step 6 (Optional) Run interface interface-type interface-number
Step 7 (Optional) Run 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. 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.
Step 8 Run commit
----End

After completing IGMP snooping proxy configuration, run the display igmp snooping [ vlan
[ vlan-id ] ] configuration command in any view to check the IGMP snooping proxy
configuration in the VLAN.

6.9 Configuring an IGMP Snooping Policy
Context
An IGMP snooping policy controls the multicast programs for users, making the multicast
network controllable and secure.
You can perform the following configuration tasks in any sequence.
6.9.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 access control list (ACL) and define rules.
For details about ACL configuration, see "ACL Configuration" in the CloudEngine 6800
Series Switches Configuration Guide - Security.
Procedure
Step 2 Use either of the following methods to configure a multicast group policy.
l Configure a multicast group policy in a VLAN.
a. Run vlan vlan-id
b. 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.
a. Run interface interface-type interface-number
b. Run igmp snooping group-policy { acl-number | acl-name acl-name } [ version
version-number ] vlan { vlan-id1 [ to vlan-id2 ] }&<1-10>
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.
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.
Step 3 Run commit
----End
6.9.2 Filtering Multicast Data on an Interface
Context
To reject certain types of multicast data, you can configure the switch to filter multicast data
packets from a certain VLAN on an interface.
The CE6870EI and CE6875EI do not support this function.
Procedure
Step 3 Run multicast deny-vlan { vlan-id1 [ to vlan-id2 ] } &<1-10>
The multicast data from specified VLANs is filtered out.
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
0x01005E).
l The packet encapsulation protocol is UDP.
Step 4 Run commit

----End
6.9.3 Dropping 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. Dropping unknown multicast flows reduces instant bandwidth usage
compared with the broadcast mode.
Procedure
Step 3 Run multicast drop-unknown
The switch is configured to drop unknown multicast flows.
If a VLANIF interface on a CE6870EI or CE6875EI switch has Layer 3 multicast enabled and is the
inbound interface of multicast flows, do not use the multicast drop-unknown command in the
corresponding VLAN. Otherwise, multicast flows may fail to be forwarded.
After the multicast drop-unknown command is configured:
l A CE6870EI or CE6875EI switch drops received unknown multicast data flows. As a result,
multicast flows may not be forwarded.
l Switches excluding the CE6870EI and CE6875EI drop the original unknown multicast data
packets. Multicast data flows can be forwarded after the matching multicast forwarding entries are
generated.
l A switch drops protocol packets with reserved group addresses, such as Protocol Independent
Multicast (PIM) Hello packets, Open Shortest Path First (OSPF) packets, and Bidirectional
Forwarding Detection (BFD) packets. If no multicast function is enabled, the switch drops IGMP
packets. If multicast functions are enabled, the switch processes IGMP packets normally.
Step 4 Run commit
----End
6.9.4 Configuring the Function of Checking the Mappings

Between Destination MAC Addresses and Destination IP
Addresses of Multicast Packets

Context
The IP multicast MAC addresses and IP addresses are mapped as follows: The 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. In an IPv6 multicast
MAC address, the leftmost 16 bits are 0x3333 and the rightmost 32 bits are mapped to the
rightmost 32 bits of an IPv6 multicast address.
After the multicast mac-ip-check enable command is run, the device checks the destination
MAC addresses and destination IP addresses of received multicast packets and performs the
following operations:
l The CE6880EI, CE6881, CE6820, CE6863, CE6875EI, CE6870EI, and CE5880EI will
discard a multicast packet if the destination MAC address and destination IP address in
the packet do not match the mapping rule.
l For the other device models, if the destination MAC address and destination IP address
in a multicast packet do not match the mapping rule:
– If only Layer 3 multicast is configured on the device and IGMP snooping and MLD
snooping for Layer 2 multicast are not configured, the device will not forward the
multicast packet to its downstream devices but will broadcast the packet in its local
ingress VLAN, instead.
– If IGMP snooping or MLD snooping for Layer 2 multicast is configured on the
device, the device will broadcast the multicast packet in its local ingress VLAN.
– To prevent multicast traffic from being broadcast in the ingress VLAN, you can run
the multicast drop-unknow command in the ingress VLAN to discard multicast
packets that do not comply with the mapping rule.
The CE6810LI does not support this function.
Procedure
Step 2 Run multicast mac-ip-check enable
The device is configured to check the mappings between destination MAC addresses and
destination IP addresses of multicast packets.
By default, the device does not check the mappings between destination MAC addresses and
destination IP addresses of multicast packets.
Step 3 For the device models except the CE6880EI, CE6881, CE6820, CE6863, CE6875EI,
CE6870EI, and CE5880EI, you need to perform the following configurations to discard the
multicast packets that do not match the mapping rule.
1. Run vlan vlan-id

2. Run multicast drop-unknown
The device is configured to drop unknown multicast flows.

Step 4 Run commit

----End
6.9.5 Configuring a Policy to Filter IGMP Report/Leave Messages
Context
You can configure a policy to filter IGMP Report/Leave messages from specified hosts to
improve security of multicast services.
This function must be used together with an access control list (ACL). When a basic ACL is
used, IGMP Report/Leave messages with specified source addresses can be filtered. When an
advanced ACL is used, IGMP Report/Leave messages with destination addresses or source
addresses can be filtered. For details on how to configure an ACL, see "ACL Configuration"
in the CloudEngine 6800 Series SwitchesConfiguration Guide - Security.
Procedure
Step 3 Run igmp snooping ip-source-policy { acl-number | acl-name acl-name }
A policy is configured to filter IGMP Report/Leave messages so that hosts in the VLAN can
only dynamically join multicast groups matching the ACL.
By default, no policy is configured to filter IGMP Report/Leave messages in a VLAN.
Step 4 Run commit
----End
6.9.6 Configuring a Policy to Filter IGMP Query Messages
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 access control list (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 Series Switches
Configuration Guide - Security.
Procedure
Step 3 Run igmp snooping query ip-source-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
6.9.7 Configuring the Multicast Group Type for a VLAN
Context
There are two multicast service models: Any-Source Multicast (ASM) and Source-Specific
Multicast (SSM). In the ASM model, packets do not carry multicast source information; while
in the SSM model, packets carry multicast source information. The ASM and SSM models
use different multicast group addresses. This function enables the switch to learn only IGMP
messages within the ASM or SSM address scope.
This function applies only to the switch that runs IGMPv3 snooping but not IGMPv1 or IGMPv2 snooping.
Procedure
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
6.9.8 Setting the Aging Time for Entries Triggered by Multicast

Traffic in a VLAN
Context
If no multicast data is sent to a multicast group, matching (S, G) or (*, G) entries need to be
deleted. Therefore, the device needs to periodically detect presence of multicast flows sent to
the multicast group to determine whether to delete the matching entry. You can set the aging
time of multicast traffic triggered entries in a VLAN. If the device does not receive multicast
data sent to a group within the aging time, the device deletes the corresponding (S, G) or (*,
G) entry. The aging time enables the device to update multicast entries and release entry
resources in a timely manner.
Procedure
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) or (*, 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 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.
Table 6-7 Recommended aging time for multicast forwarding entries in a VLAN
Number of Entries Recommended Aging Time
1000 to 2000 1000 seconds
2000 to 8000 2000 seconds
More than 8000 3000 seconds or 4000 seconds
Step 4 Run commit

----End
6.9.9 Verifying the IGMP Snooping Policy Configuration
Prerequisites
After the IGMP snooping policy configuration is 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
6.10 Configuring IGMP Snooping Membership Fast-

Update
Context
The switch can be 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.
You can perform the following configuration tasks in any sequence.
6.10.1 Setting the Aging Time of Group Member Ports
Context
The switch determines 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 switch
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 switch
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 IGMP snooping general query interval. Otherwise, errors may occur in Layer 2
multicast forwarding.
Procedure
Step 3 Run igmp snooping query interval query-interval
The IGMP snooping general query interval is configured.
By default, the IGMP snooping general query interval is 60 seconds.
Step 4 Run igmp snooping robust-count robust-count
The IGMP snooping robustness variable is configured.
By default, the IGMP snooping robustness variable is 2.
Step 5 Run igmp snooping query max-response-time max-response-time
The IGMP snooping maximum response time is set.
By default, the IGMP snooping maximum response time is 10 seconds.
Step 6 Run igmp snooping query last-member-interval last-member-interval
The IGMP snooping last member query interval is configured.
By default, the IGMP snooping last member query interval is 1 second.
Step 7 Run commit
----End
6.10.2 Setting the Aging Time of Dynamic Router Ports
Context
A router port sends IGMP Report/Leave 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 multicast data transmission.
When network congestion or flapping occurs, the dynamic router port does not receive

General IGMP Query or Protocol Independent Multicast (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 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
6.10.3 Configuring Fast Leave for Member Ports
Context
When the switch receives IGMP Leave messages from a group member port, the fast leave
function allows the switch to immediately delete forwarding entries of the member port but
does not reset the aging timer.
l The CE6810LI does not support fast leave of member ports.

l Enable fast leave in a VLAN only when each interface in the VLAN is connected to one receiver
host.
l Fast leave takes effect for member ports in a VLAN only when the switch can process IGMPv2 or
IGMPv3 messages.
Procedure
Step 3 Run igmp snooping prompt-leave [ group-policy { acl-number | acl-name acl-name } ]
Fast 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 access control list (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 Series SwitchesConfiguration Guide - Security.
Step 4 Run commit
----End
6.10.4 Configuring the Host Tracking Function
Context
On a network running IGMPv3, IGMPv3 hosts in a VLAN receive multicast traffic through
multicast groups. When an IGMPv3 host leaves a multicast group, the IGMP querier sends a
Group-Specific Query message to the host. If the querier does not receive any response from
the host within the specified time, it considers that the host has left the multicast group and
deletes the corresponding forwarding entry. While the IGMP querier waits for a response
from the host, the multicast device continues to forward multicast traffic to the host. This
delays the switching of multicast programs and wastes bandwidth.
You can configure the host tracking function to address this problem. After this function is
enabled, the IGMP querier will create an entry when a host joins a group. Upon receipt of a
Leave message sent by a host, the IGMP querier considers that the host has left the multicast
group and stops sending Group-Specific Query messages.
Before configuring host tracking in a VLAN, ensure that IGMP snooping can process
IGMPv3 messages in the VLAN. Host tracking applies only to scenarios where multicast
hosts and multicast devices are both running IGMPv3.
Procedure
Step 3 Run igmp snooping explicit-tracking
The host tracking function is enabled in the VLAN.
By default, host tracking is disabled in a VLAN.
Step 4 Run commit

----End
6.10.5 Sending IGMP Query Messages upon Topology Changes
Context
Changes of the Layer 2 network topology may trigger changes of the multicast forwarding
paths. When a link fails, the switch sends IGMP Query messages and the group 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
switched to new forwarding paths quickly.
Procedure
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 update information about multicast
member ports quickly, so that multicast packets to the downstream members are interrupted
only for a short period.
Step 3 (Optional) Run 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 another device on the network, use this
command to set another IP address.
Step 4 Run commit
----End
6.10.6 Verifying the IGMP Snooping Membership Fast-Update

Configuration
Prerequisites
After the membership fast-update configuration is complete, you can run the following
commands in any view to check the IGMP snooping configuration and forwarding entries.

Procedure
IGMP snooping configuration.
group group-address] ] command to check the multicast forwarding table in a VLAN.
----End
6.11 Configuring IGMP Snooping SSM Mapping
Context
If user hosts on a Layer 2 network run only IGMPv1 or IGMPv2, enable Source-Specific
Multicast (SSM) mapping on the switch to provide SSM services for these hosts.
6.11.2 Configuring IGMP Snooping SSM Mapping Functions is mandatory and 6.11.1
(Optional) Configuring an SSM Group Policy is optional.
6.11.1 (Optional) Configuring an SSM Group Policy
Context
By default, the address of a Source-Specific Multicast (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
Series Switches Configuration Guide - Security.
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 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
6.11.2 Configuring IGMP Snooping SSM Mapping Functions
Context
l By configuring Source-Specific Multicast (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 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 6.11.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:
a. Run the quit command to return to the system view.
b. Run the ssm-mapping policy policy-name command to enter the SSM mapping
policy view.
c. Run the group group-address { group-mask-length | group-mask } source source-
address 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
apply the same mapping to multiple VLANs, you are advised to configure an SSM mapping
policy.
Step 6 Run commit
----End
6.11.3 Verifying the IGMP Snooping SSM Mapping

Configuration
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 information about IGMP snooping interfaces.
----End
6.12 Maintaining IGMP Snooping
6.12.1 Clearing IGMP Snooping Entries
Context
IGMP snooping entries are classified into static and dynamic entries, and they are cleared in
different ways.

NOTICE
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.
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.
l Run the reset igmp snooping qinq-group { all | interface interface-type interface-
number [ pe-vid pe-vid [ group-address [ mask { group-mask | group-mask-length } ]
[ source-address [ mask { source-mask | source-mask-length } ] ] ] ] } command in the
user view to remove multicast entries on the Layer 3 sub-interfaces.
----End
6.12.2 Clearing IGMP Snooping Statistics
Context
IGMP snooping statistics include the number of IGMP Report, Leave, Query, and Hello
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.
NOTICE
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

6.12.3 Monitoring the IGMP Snooping Running Status
Context
To check the IGMP snooping running status during routine maintenance, run the following
display commands in any view.
Procedure
l Run the display igmp snooping [ vlan [ vlan-id ] ] command to check all the IGMP
snooping running parameters in a VLAN.
IGMP snooping configuration in a VLAN.
l Run the display igmp snooping qinq-port-info interface interface-type interface-
number [ group-address group-address ] command to check the entries about multicast
groups on the Layer 3 sub-interface.
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.
group group-address ] ] command to check the multicast forwarding table in a VLAN.
l Run the display igmp snooping group [ interface interface-type interface-number
{ vlan vlan-id | pe-vid pe-vid } [ [ source-address source-address ] group-address
group-address ] ] command to check information about multicast groups that are learned
dynamically.
----End
6.12.4 Configuring the Maximum Number of Invalid Layer 2

Multicast Protocol Packets Allowed on a Multicast Device
Usage Scenario
If forwarding entries cannot be created on a multicast network, configure the maximum
number of invalid Layer 2 multicast protocol packets allowed on a multicast device. Then,
you can locate and rectify the fault based on statistics and detailed information about invalid
Layer 2 multicast protocol packets.
Procedure


Step 2 Run multicast layer-2 invalid-packet igmp snooping max-count max-number
The maximum number of invalid Layer 2 multicast protocol packets allowed on a multicast
device is specified.
By default, a multicast device can store a maximum of 10 invalid Layer 2 multicast protocol
packets.
Step 3 Run commit
----End

l Run the display current-configuration | include multicast layer-2 invalid-packet
command to check the maximum number of invalid Layer 2 multicast protocol packets
allowed on a multicast device.
l Run the display igmp snooping invalid-packet vlan [ vlan-id ] [ message-type { leave |
query | report | hello } ] command to check statistics about invalid Layer 2 multicast
protocol packets stored on a multicast device.
l Run the display igmp snooping invalid-packet [ packet-number ] verbose command to
check detailed information about invalid Layer 2 multicast protocol packets stored on a
multicast device.
6.13 Configuration Examples for IGMP Snooping

6.13.1 Example for Configuring IGMP Snooping
As shown in Figure 6-7, Router connects to user hosts through a Layer 2 Switch and Router
runs IGMPv2. The multicast source (Source) sends data to multicast groups 225.1.1.1 to
225.1.1.5. There are three receivers HostA, HostB, and HostC on the network. The receivers
are only allowed to receive data of groups 225.1.1.1 to 225.1.1.3.

Figure 6-7 Networking diagram for IGMP snooping configuration

Source
PIM network
Router
VLAN10 10GE1/0/3
10GE1/0/1 10GE1/0/2
Switch
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] 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
[~Switch-10GE1/0/3] quit
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
[~Switch-vlan10] quit
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 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 T:Trill
(Source, Group) Port Flag
-------------------------------------------------------------------------------
VLAN 10, 5 Entry(s)
(*, 225.1.1.1) PA-
10GE1/0/1 -D-
10GE1/0/2 -D-
2 port(s) include
(*, 225.1.1.2) PA-
10GE1/0/1 -D-
10GE1/0/2 -D-
2 port(s) include
(*, 225.1.1.3) PA-
10GE1/0/1 -D-
10GE1/0/2 -D-
2 port(s) include
(*, 225.1.1.4) -A-
(*, 225.1.1.5) -A-
-------------------------------------------------------------------------------
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, whereas groups 225.1.1.4
and 225.1.1.5 have no member ports.
# 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 12h03m12s 00h02m31s DYNAMIC
The command output shows that the router port is 10GE1/0/3.

# 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 5
(*, 225.1.1.1) 10GE1/0/1
10GE1/0/2
10GE1/0/3
(*, 225.1.1.2) 10GE1/0/1
10GE1/0/2
10GE1/0/3
(*, 225.1.1.3) 10GE1/0/1
10GE1/0/2
10GE1/0/3
(*, 225.1.1.4) 10GE1/0/3
(*, 225.1.1.5) 10GE1/0/3
--------------------------------------------------------------------------------
According to the preceding command output, only groups 225.1.1.1 to 225.1.1.3 have
member ports in the multicast forwarding table, and multicast data of these groups can be
forwarded to the hosts. Groups 225.1.1.4 and 225.1.1.5 have no member ports, and multicast
data of the two groups is not forwarded to the host.
----End
Configuration Files
#
sysname Switch
#
vlan batch 10
#
#
vlan 10
igmp snooping group-policy 2000
#
acl number 2000
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
return
6.13.2 Example for Configuring IPv4 Layer 2 Multicast Through

Static Interfaces

As shown in Figure 6-8, Router connects to user hosts through a Layer 2 switch. 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.
Figure 6-8 Networking diagram for Layer 2 multicast configuration through static interfaces
Source
PIM network
Router
VLAN10 10GE1/0/3
10GE1/0/1 10GE1/0/2
Switch
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] commit
[~Switch] vlan 10




[*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] interface 10ge 1/0/1
[~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 T:Trill
(Source, Group) Port Flag
-------------------------------------------------------------------------------
VLAN 10, 5 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--
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
10GE1/0/3
(*, 225.1.1.2) 10GE1/0/1
10GE1/0/3
(*, 225.1.1.3) 10GE1/0/1
10GE1/0/3
(*, 225.1.1.4) 10GE1/0/2
10GE1/0/3
(*, 225.1.1.5) 10GE1/0/2
10GE1/0/3
--------------------------------------------------------------------------------
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

6.13.3 Example for Configuring an IGMP Snooping Querier
As shown in Figure 6-9, 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 join
multicast group 224.1.1.1, while HostB and HostD join multicast group 225.1.1.1. All the
hosts run IGMPv2. Multicast data is expected to be transmitted on the Layer 2 network
through IGMP snooping.
Figure 6-9 Networking diagram for IGMP snooping querier configuration

Source1 Source2
VLAN10
10GE1/0/3 10GE1/0/4
10GE1/0/1 10GE1/0/2 10GE1/0/3

10GE1/0/2
HostA SwitchA SwitchB 10GE1/0/1 HostB
10GE1/0/1
10GE1/0/1 10GE1/0/2
10GE1/0/2 10GE1/0/3
HostD SwitchD SwitchC HostC
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
6-9.
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] commit
[~SwitchA] vlan 10
[*SwitchA-10GE1/0/3] commit
[~SwitchA-10GE1/0/3] quit
# The configurations of SwitchB, SwitchC and SwitchD are similar to the configuration of
Step 2 Enable IGMP snooping globally and in the VLAN on all the Switches.
[*SwitchA] vlan 10
[*SwitchA-vlan10] commit
[~SwitchA-vlan10] quit
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
Receive 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
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
multicast drop-unknown
#
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
#
#
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
6.13.4 Example for Configuring IGMP Snooping Proxy
As shown in Figure 6-10, 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.

Figure 6-10 Networking diagram for the IGMP snooping proxy configuration
Source
PIM network
Router
VLAN10 10GE1/0/3
10GE1/0/1 10GE1/0/2
Switch
HostA HostG HostH HostN
To meet the preceding requirements, configure IGMP snooping proxy on the Switch. The
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



[*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] interface 10ge 1/0/3
[~Switch-10GE1/0/3] igmp snooping proxy-uplink-port vlan 10
# Check IGMP message statistics on the Switch.

[~Switch] display igmp snooping statistics vlan 10
IGMP Snooping Packets
Counter:
Statistics for VLAN
10
Receive V1 Report:
0
Receive V2 Report:
1121
Receive V3 Report:
0
Receive V1 Query:
0
Receive V2 Query:
2
Receive V3 Query:
0
Receive Leave:
0
Receive Pim Hello:
4
Send Query (S=0):
0
Send Query (S!=0):
-
Proxy Send General Query: 13
Proxy Send Group-Specific Query:
0
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
Configuration Files
#
sysname Switch
#
vlan batch 10
#
#
vlan 10
igmp snooping version 3
igmp snooping proxy
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
igmp snooping proxy-uplink-port vlan 10
#
return
6.13.5 Example for Configuring IGMP Snooping SSM Mapping
This configuration example is not applicable to the CE6810LI.
As shown in Figure 6-11, Router connects to user hosts through a Layer 2 Switch. Router
runs IGMPv3 and uses the Any-Source Multicast (ASM) model and Source-Specific
Multicast (SSM) model 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.

Figure 6-11 Networking diagram for SSM mapping configuration
Source2
PIM network
10.10.2.1
Source1
10.10.1.1
Router
VLAN10 10GE1/0/3
Switch
10GE1/0/1
HostA HostB HostC
To meet the preceding requirements, configure SSM mapping on the Switch. The

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



[*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.
[~Switch] acl number 2008
[*Switch-acl4-basic-2008] rule 5 permit source 225.1.1.1 0
[*Switch-acl4-basic-2008] commit
[~Switch-acl4-basic-2008] quit
# Apply the SSM mapping policy in the VLAN and treat the multicast group 225.1.1.1 as a
member in the SSM groups.
[~Switch] vlan 10
[~Switch-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.
[~Switch-vlan10] igmp snooping version 3
[*Switch-vlan10] igmp snooping ssm-mapping enable
[*Switch-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-policy 2008
igmp snooping ssm-mapping enable
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
10GE1/0/3
--------------------------------------------------------------------------------

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-policy 2008
igmp snooping ssm-mapping enable
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
6.14 Troubleshooting IGMP Snooping
6.14.1 IPv4 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 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 the general query interval configured on the local device is the same as that
configured on the upstream device.
If the general query interval on the local device is smaller than the general query interval on
the upstream IGMP querier or IGMP snooping device, the local device may age out some
IGMP snooping entries that are still in use. As a result, multicast packets matching these
entries cannot be forwarded.
Run the display igmp snooping command to check IGMP snooping parameters. If the
general query interval on the local device is smaller than the general query interval on the
upstream IGMP querier or IGMP snooping device, run the igmp snooping query-interval
query-interval command to increase the IGMP snooping general query interval. It is
recommended that the upstream and downstream devices use the same general query interval.
Step 3 Check whether router port dynamic learning is disabled.
The switch does not listen to IGMP Query messages in a VLAN or BD after router port
dynamic learning is disabled in the VLAN or BD.
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 or BD.
Step 4 Check whether fast leave for member ports is enabled.
Configure fast leave in a VLAN or BD only when each interface in the VLAN or BD
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 or BD, 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 or BD view to disable the
fast leave function.
Step 5 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 or BD view to
delete the related configuration.
Step 6 Check whether a multicast group policy is configured.
The multicast group policy limits the multicast groups that the hosts in a VLAN or BD can
join. Run the display igmp snooping configuration command to verify the configuration of
multicast group policy. If an access control list (ACL) is configured, run the display acl
command to verify the ACL configuration.
Step 7 Check whether the Layer 2 multicast filtering function is configured. (This function cannot be
supported on the CE6870EI, CE6875EI or a BD where IGMP snooping 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
6.14.2 Configured IPv4 Multicast Group Policy Takes Ineffective
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 access control list (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 or BD. If not, run the igmp snooping group-
policy command to apply a correct multicast group policy in the VLAN or BD.
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

Configuration Guide - IP Multicast 7 Static Multicast MAC Address Configuration
7 Static Multicast MAC Address

Configuration
This chapter describes how to configure mappings between multicast MAC addresses and
interfaces on a Layer 2 device, so that multicast packets destined for the specified multicast
MAC address are only forwarded to these interfaces. This reduces broadcast packets on a
Layer 2 network.
7.1 Overview of Multicast MAC Addresses

7.2 Licensing Requirements and Limitations for Static Multicast MAC Addresses
7.3 Configuring a Static Multicast MAC Address
7.4 Configuration Examples for Static Multicast MAC Addresses
7.1 Overview of Multicast MAC Addresses

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 value 1 of this bit indicates a 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 7-1 Multicast MAC address

48-bit MAC address
7 0 7 0 7 0 7 0 7 0 7 0
XXXXXXX1 XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
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 7-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.
5 bits information loss
XXXX X
32-bit IP address 1110 XXXX X XXXXXXX XXXXXXXX XXXXXXXX
...... 23 bits ......

mapping
48-bit MAC address

00000001 00000000 01011110 0 XXXXXXX XXXXXXXX XXXXXXXX
25 bits MAC address prefix
7.2 Licensing Requirements and Limitations for Static

Multicast MAC Addresses

a multicast source.


Static multicast MAC address binding is a basic software function of the switch. The license
for basic software functions has been loaded and activated before delivery. You do not need to

Required
CE5810EI V100R002C00
CE5850EI V100R001C00
CE5850HI V100R003C00
CE5855EI V100R005C10
CE5880EI V200R005C10
CE6810-48S4Q-LI/CE6810-48S-LI V100R003C10
CE6810-32T16S4Q-LI/CE6810-24S2Q-LI V100R005C10
CE6810EI V100R003C00
CE6850EI V100R001C00
CE6850-48S6Q-HI V100R005C00
CE6855HI V200R001C00
CE6856HI V200R002C50
CE6857EI V200R005C10
CE6860EI V200R002C50
CE6865EI V200R005C00
CE6870-48T6CQ-EI V200R002C50
CE6875EI V200R003C00
CE6880EI V200R002C50


Required
CE6881/CE6820/CE6863 V200R005C20
CE7850EI V100R003C00
CE7855EI V200R001C00
CE8850-32CQ-EI V200R002C50
CE8850-64CQ-EI V200R005C00
CE8860EI V100R006C00
CE8861EI/CE8868EI V200R005C10
Feature Limitations
l 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.
l Before configuring a static multicast MAC address on an interface, ensure that the
interface does not belong to a super VLAN.
l If the static multicast MAC address configured on an interface is an IPv4 multicast MAC
address (starting with 0x0100-5e and ending with bit 0), the validity of the static
multicast MAC address in different scenarios is listed in the following table.
Scenario Valid or invalid
No other multicast services configured Valid
Layer 3 multicast or both Layer 2 and Valid

Layer 3 multicast configured
IP address-based Layer 2 multicast Valid, but may cause conflicts

forwarding
MAC address-based Layer 2 multicast Valid, but may cause conflicts

forwarding
A conflict occurs in the following situation: If IGMP snooping is enabled, the switch
forwards multicast packets based on destination MAC addresses of the packets. When a
static multicast MAC address is configured, a conflict may occur, causing data
forwarding errors. For example, VRRP sends protocol packets using IP multicast address
224.0.0.18, which is mapped to IP multicast MAC address 01-00-5E-00-00-12. If this IP
multicast MAC address is configured as a static multicast MAC address on an interface,
VRRP protocol packets cannot be forwarded normally.
l An M-LAG does not support static multicast MAC addresses.

7.3 Configuring a Static Multicast MAC Address
Before configuring a static multicast MAC address, create a VLAN and add 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 Internet Group Management Protocol (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 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.
Procedure
Step 2 Configure a static multicast MAC address using the following two methods:
l Configure a static multicast MAC address on an interface:
a. Run interface interface-type interface-number
b. 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-idA 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.
7.4 Configuration Examples for Static Multicast MAC

Addresses
7.4.1 Example for Configuring a Static Multicast MAC Address
As shown in Figure 7-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 7-3 Network diagram for configuring a static multicast MAC address
Source
IP/MPLS core
Router
VLAN10 10GE1/0/4
10GE1/0/1 10GE1/0/2
Switch 10GE1/0/3
HostA HostB HostC

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
[*Switch] interface 10GE 1/0/1
[*Switch] commit
Step 2 Configure a static multicast MAC address.

[~Switch] interface 10GE 1/0/1
[~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
10GE1/0/2
2 port(s)
--------------------------------------------------------------------
Total Group(s) : 1
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

Configuration Guide - IP Multicast 8 Multicast VLAN Replication Configuration
8 Multicast VLAN Replication Configuration
This chapter describes how to configure the multicast VLAN replication function to conserve
network bandwidth. After this function is enabled, the upstream device only needs to transmit
multicast data to a multicast VLAN, instead of sending copy of multicast data to each user
VLAN.
8.1 Overview of Multicast VLAN Replication

8.2 Understanding Multicast VLAN Replication
8.3 Summary of Multicast VLAN Replication Configuration Tasks
8.4 Licensing Requirements and Limitations for Multicast VLAN Replication
8.5 Default Settings for Multicast VLAN Replication
8.6 Configuring Multicast VLAN Replication Based on User VLANs
8.7 Configuring Interface-based Multicast VLAN Replication
8.8 Configuration Examples for Multicast VLAN Replication
8.9 Troubleshooting Multicast VLAN Replication
8.1 Overview of Multicast VLAN Replication
Definition
Multicast VLAN replication is used to distribute the same multicast data to different user
VLANs.
Purpose
On a Layer 2 broadcast network, multicast data is broadcast to all hosts. Internet Group
Management Protocol (IGMP) snooping solves this problem but it takes effect only within a
VLAN. If users in different VLANs require the same multicast data, the upstream router still
has to send multiple copies of identical multicast data to different VLANs.
Multicast VLAN replication can be configured on a Layer 2 device to implement multicast
data replication across VLANs. After this function is configured, the upstream router

replicates multicast data in the multicast VLAN and sends only one copy to the Layer 2
device, instead of sending several identical multicast data flows downstream. This saves
network bandwidth and reduces the burden on the router.
8.2 Understanding Multicast VLAN Replication
Multicast VLAN Replication Based on User VLANs

Switches support the binding between multicast and user VLANs, allowing multicast packet
replication in different user VLANs. This binding is the core of the multicast VLAN
replication function. In Figure 8-1, the upstream router only needs to send one copy of the
multicast data to the switch configured with multicast VLAN replication. The switch then
copies multicast data and sends the data to different user VLANs. This reduces bandwidth
consumption between the upstream router and the switch.

Figure 8-1 VLAN-based multicast VLAN replication

No multicast VLAN
Multicast VLAN configured
configured
Source Source
PIM PIM
network network
Router Router
Switch Switch
VLAN2 VLAN3 VLAN4 VLAN3 VLAN4
Receiver Receiver Receiver Receiver Receiver Receiver

HostA HostB HostC HostA HostB HostC
Multicast Packet
VLAN 2
VLAN 3
VLAN 4
VLAN 5 (multicast VLAN)
Interface-based Multicast VLAN Replication

Switches support the binding between user and multicast VLANs on user-side interfaces. This
allows multicast data to be replicated for different user VLANs and implements interface-
based multicast service isolation.
In Figure 8-2, ISP1 and ISP2 provide multicast services on the network. HostA and HostB
obtain multicast services from ISP1, whereas HostC and HostD obtain multicast services from
ISP2. To prevent multicast data from being sent to all hosts, the following configuration can
be performed: Configure MVLAN1 and MVLAN2 for ISP1 and ISP2, respectively. Bind
UVLAN to MVLAN1 on access interfaces of HostA and HostB. Bind UVLAN to MVLAN2
on access interfaces of HostC and HostD. In this way, multicast data provided by ISP1 is sent
to HostA and HostB, and multicast data provided by ISP2 is sent to HostC and HostD.

Figure 8-2 Interface-based multicast VLAN replication

Source
PIM
network
Router
SwitchA
UVLAN
SwitchB SwitchC

Receiver Receiver Receiver Receiver
Multicast packets from ISP1

Multicast packets from ISP2
MVLAN1
MVLAN2
UVLAN
8.3 Summary of Multicast VLAN Replication

Configuration Tasks
Multicast VLAN replication can be configured in different methods depending on the
application scenario. Table 8-1 lists multicast VLAN replication configuration tasks.

Table 8-1 Multicast VLAN replication configuration tasks

Task Description
8.6 Configuring Multicast VLAN When user VLAN-based multicast VLAN

Replication Based on User VLANs replication is configured on a switch, the
upstream device only needs to send one
copy of multicast data to the switch. The
switch then replicates multicast data and
sends the data to multiple user VLANs. This
saves bandwidth between the upstream
device and the switch.
8.7 Configuring Interface-based By binding user VLANs to a multicast

Multicast VLAN Replication VLAN on a user-side interface, you can
implement multicast service isolation on the
interface while allowing multicast data
replication to user VLANs. For example,
when multiple ISPs provide multicast
services on a network, you can configure
this function to ensure that data of an ISP is
forwarded only to the users who have
subscribed to the services of the ISP.
8.4 Licensing Requirements and Limitations for Multicast

VLAN Replication

a multicast source.


a multicast source.
Multicast VLAN replication is a basic software function of the switch. The license for basic
software functions has been loaded and activated before delivery. You do not need to
Table 8-2 Products and minimum versions supporting multicast VLAN replication
Required
CE5810EI V100R002C00
CE5850EI V100R002C00
CE5850HI V100R003C00
CE5855EI V100R005C10
CE5880EI V200R005C10
CE6810EI V100R003C00


Required
CE6850EI V100R002C00
CE6850-48S6Q-HI V100R005C00
CE6855HI V200R001C00
CE6856HI V200R002C50
CE6857EI V200R005C10
CE6860EI V200R002C50
CE6865EI V200R005C00
CE6870-48T6CQ-EI V200R002C50
CE6875EI V200R003C00
CE6880EI V200R002C50
CE6881/CE6820/CE6863 V200R005C20
CE7850EI V100R003C00
CE7855EI V200R001C00
CE8850-32CQ-EI V200R002C50
CE8850-64CQ-EI V200R005C00
CE8860EI V100R006C00
CE8861EI/CE8868EI V200R005C10
Feature Limitations
l Because multicast VLAN replication is a Layer 2 multicast feature, all the multicast
VLAN replication configurations on interfaces mentioned in this chapter are performed
on Layer 2 physical interfaces, including Eth-Trunk interfaces.
l A proper time to live (TTL) value needs to be set for multicast data packets sent from a
multicast source. This ensures that the TTL value is larger than 1 when the device
receives the packets from the multicast VLAN. Otherwise, the multicast data packets
may fail to be forwarded to user VLANs.
8.5 Default Settings for Multicast VLAN Replication

Table 8-3 lists the default settings for multicast VLAN replication.

Table 8-3 Default settings for multicast VLAN replication

Multicast VLAN replication based on user Disabled

VLANs
Multicast VLAN replication based on Disabled

interfaces
8.6 Configuring Multicast VLAN Replication Based on

User VLANs
Context
Multicast VLAN replication based on user VLANs enables a switch to copy and send
multicast data to different user VLANs, reducing bandwidth consumption on the upstream
device.
Perform the configuration in the listed sequence:
8.6.1 Configuring a User VLAN

Context
When you configure multicast VLAN replication based on user VLANs, you must enable
Layer 2 IGMP snooping in user VLANs.
Procedure
A VLAN is created, and the VLAN view is displayed.
Step 5 Run commit
----End

8.6.2 Binding User VLANs to a Multicast VLAN
Context
Multicast VLAN replication is implemented based on the multicast VLAN, which aggregates
multicast flows from the network side. It allows the device to copy and deliver multicast
packets in user VLANs. When you configure multicast VLAN replication based on user
VLANs, you must enable Layer 2 multicast snooping in the multicast VLAN.
If two devices connect to the same user VLAN and both have the multicast VLAN
configured, hosts in the user VLAN will receive two copies of a multicast flow. To avoid this
problem, enable querier election for user VLANs in the multicast VLAN view on both the
devices. Only the device that wins the querier election can generate Layer 2 multicast
forwarding entries according to received Report messages.
Procedure
Step 5 Run multicast vlan enable
Multicast VLAN is enabled and the current VLAN is configured as a multicast VLAN.
Step 6 Run multicast vlan user-vlan { vlan-id1 [ to vlan-id2 ] } &<1-10>
The binding between a multicast VLAN and user VLANs is configured and user VLANs are
bound to a multicast VLAN.
When you configure the binding between a multicast VLAN and user VLANs, a user VLAN can be
bound to only one multicast VLAN.
Step 7 (Optional) Run multicast vlan igmp-querier-election user-vlan { vlan-id1 [ to vlan-id2 ] }

&<1-10>
The querier election is enabled for the user VLANs.
By default, the querier election is disabled.
Before enabling querier election, ensure that a source IP address has been configured on each switch for
the Query messages sent by the device using the igmp snooping send-query source-address command.

Step 8 Run commit
----End
8.6.3 Adding Interfaces to VLANs
Context
After a multicast VLAN and a user VLAN are configured, you can add a network-side
interface to the multicast VLAN and a user-side interface to the user VLAN.
Procedure
Step 1 Add network-side the interface to the multicast VLAN. For details, see Configuring Interface-
based VLAN Assignment.
Step 2 Add the user-side interface to the user VLAN. For details, see Configuring Interface-based
VLAN Assignment.
----End
8.6.4 Verifying the Configuration of Multicast VLAN Replication

Based on User VLANs
Prerequisites
The configuration of multicast VLAN replication is complete.
Procedure
l Run the display multicast vlan mvlan [ vlan-id ] command to view information about a
multicast VLAN.
l Run the display multicast vlan user-vlan [ vlan-id ] command to view information
about a user VLAN.
----End
8.7 Configuring Interface-based Multicast VLAN

Replication
Interface-based multicast VLAN replication implements multicast service isolation in the
same user VLAN and improves control on multicast service flows.
Perform the configuration in the listed sequence:

8.7.1 Configuring a User VLAN
Context
When you configure interface-based multicast VLAN replication, you must enable Layer 2
configuration file snooping in user VLANs.
Procedure
Step 5 Run commit
----End
8.7.2 Configuring IGMP Snooping in a Multicast VLAN
Context
When configuring interface-based multicast VLAN replication, you only need to enable
IGMP snooping in a multicast VLAN. Multicast VLAN replication does not need to be
enabled.
Procedure
Step 5 Run commit

----End
8.7.3 Binding User VLANs to a Multicast VLAN
Context
A user VLAN can be bound to a multicast VLAN on a user side interface. A user VLAN
cannot be bound to more than one multicast VLAN on the same interface.
Procedure
Step 3 Run multicast layer-2 bind vlan vlan-id1 [ to vlan-id2 ] mvlan mvlan-id
User VLANs are bound to a multicast VLAN on the interface.
Step 4 Run commit
----End
8.7.4 Adding Interfaces to VLANs
Context
After a multicast VLAN and a user VLAN are configured, you can add a network-side
interface to the multicast VLAN and a user-side interface to the user VLAN.
Procedure
Step 1 Add network-side the interface to the multicast VLAN. For details, see Configuring Interface-
based VLAN Assignment.
Step 2 Add the user-side interface to the user VLAN. For details, see Configuring Interface-based
VLAN Assignment.
----End
8.7.5 Verifying the Interface-based Multicast VLAN Replication

Configuration
Prerequisites
The configuration of interface-based multicast VLAN replication is complete.

Procedure
l Run the display multicast layer-2 bind [ mvlan vlan-id ] command to view the binding
relationship between multicast VLANs and user VLANs on the interface.
----End
8.8 Configuration Examples for Multicast VLAN

Replication
8.8.1 Example for Configuring Multicast VLAN Replication Based

on User VLANs
in Figure 8-3, service VLAN 10 is used to transmit multicast data between RouterA and
SwitchA. HostA, HostB, and HostC belong to VLAN 100, VLAN 200, and VLAN 300,
respectively. All of them want to receive multicast data from Source.
You can configure multicast VLAN replication based on user VLANs, so that RouterA only
needs to send multicast data to VLAN 10 in response to the same multicast data request from
different user hosts. This reduces bandwidth consumption between RouterA and SwitchA.
Figure 8-3 Configuring multicast VLAN replication based on user VLANs
RouterA
Source
VLAN10
10GE1/0/0 SwitchA
10GE1/0/2 10GE1/0/4
10GE1/0/3
VLAN100 VLAN200 VLAN300
HostA HostB HostC

Receiver Receiver Receiver

1. Enable IGMP snooping in the system view.
2. Create user VLANs and enable IGMP snooping in the user VLANs.
3. Create a multicast VLAN and enable IGMP snooping in the multicast VLAN.
4. Bind the user VLANs to the multicast VLAN.
5. Add the network-side interface and user-side interfaces to the VLANs as access
interfaces.
Procedure
Step 1 Enable IGMP snooping in the system view.
[*HUAWEI] commit
[*SwitchA] commit
Step 2 Create user VLANs and enable IGMP snooping in the user VLANs.
[~SwitchA] vlan 100
[*SwitchA] vlan 200
[*SwitchA] vlan 300
Step 3 Create a multicast VLAN and enable IGMP snooping in the multicast VLAN.
[~SwitchA] vlan 10
[*SwitchA-vlan10] multicast vlan enable
Step 4 Bind user VLANs 100, 200, and 300 to multicast VLAN 10.
[~SwitchA-vlan10] multicast vlan user-vlan 100 200 300
Step 5 Add interfaces to the VLANs.

# Add 10GE1/0/1 to multicast VLAN 10, and configure 10GE1/0/1 to allow all the user
VLANs.
[~SwitchA-10GE1/0/1] port link-type trunk
[*SwitchA-10GE1/0/1] port trunk pvid vlan 10
[*SwitchA-10GE1/0/1] port trunk allow-pass vlan 10 100 200 300
# Add 10GE1/0/2, 10GE1/0/3, and 10GE1/0/4 to user VLANs 100, 200, and 300 respectively.
[~SwitchA-10GE1/0/2] port link-type access


On RouterA, configure a Layer 3 sub-interface on the interface connected to SwitchA to terminate

packets of VLAN 10, VLAN 100, VLAN 200, and VLAN 300.
Step 6 Verify the configuration. View information about the multicast VLAN and user VLANs on
SwitchA.
[~SwitchA] display multicast vlan mvlan
Total: 1
multicast-vlan user-vlan number snooping-state
----------------------------------------------------------------
10 3 IGMP Enable
[~SwitchA] display multicast vlan user-vlan
Total: 3
user-vlan snooping-state multicast-vlan snooping-state
-----------------------------------------------------------------------------
100 IGMP Enable 10 IGMP Enable
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 100 200 300
#
#
vlan 10
multicast vlan enable
multicast vlan user-vlan 100 200 300
#
vlan 100
#
vlan 200
#
vlan 300
#
interface 10GE1/0/1
port trunk pvid vlan 10
port trunk allow-pass vlan 10 100 200 300
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4


#
return
8.8.2 Example for Configuring Interface-based Multicast VLAN

Replication
In Figure 8-4, 10GE1/0/1 of the SwitchA is connected to the Router. 10GE1/0/2 provides
services for ISP1, and 10GE1/0/3 provides services for ISP2. ISP1 and ISP2 use multicast
VLAN 2 and VLAN 3 respectively to provide multicast services for users. 10GE1/0/2 and
10GE1/0/3 have the same user VLAN (VLAN 10).
To ensure that multicast packets of each ISP are sent only to users of the ISP, interface-based
multicast VLAN replication is required. After the configuration is complete, multicast data of
an ISP will be sent only to the interface connected to the ISP.
Figure 8-4 Configuring interface-based multicast VLAN replication
Router
Source
10GE1/0/1
10GE1/0/2 10GE1/0/3
SwitchA
ISP1 ISP2
VLAN10 VLAN10
Receiver Receiver
HostA HostB
Multicast Packet
Multicast VLAN 2
Multicast VLAN 3
1. Enable Internet Group Management Protocol (IGMP) snooping in the system view.

2. Create user VLAN 10 and enable IGMP snooping in the user VLAN.
3. Create multicast VLANs 2 and 3 and enable IGMP snooping in the multicast VLANs.
4. Bind user VLAN 10 to multicast VLANs on 10GE1/0/2 and 10GE1/0/3 respectively.
5. Add the network-side interface and user-side interfaces to the VLANs.
Procedure
Step 1 Create user VLAN 10 and enable IGMP snooping in the user VLAN.
[*HUAWEI] commit
[*SwitchA] vlan 10
Step 2 Create multicast VLANs 2 and 3 and enable IGMP snooping in the multicast VLANs.
[~SwitchA] vlan 2
[*SwitchA] vlan 3
Step 3 Bind user VLAN 10 to multicast VLANs on 10GE1/0/2 and 10GE1/0/3 respectively.
[~SwitchA-10GE1/0/2] multicast layer-2 bind vlan 10 mvlan 2
[*SwitchA-10GE1/0/3] multicast layer-2 bind vlan 10 mvlan 3
Step 4 Add 10GE1/0/1 to the multicast VLANs. Add 10GE1/0/2 and 10GE1/0/3 to the user VLAN.
# Add 10GE1/0/1 to multicast VLANs 2 and 3 as a trunk interface.
[*SwitchA-10GE1/0/1] port trunk allow-pass vlan 2 3
# Add 10GE1/0/2 and 10GE1/0/3 respectively to user VLAN 10 as trunk interfaces.


Run the display multicast layer-2 bind command on SwitchA to view binding between the
user VLAN and multicast VLANs.
[~SwitchA] display multicast layer-2 bind
-------------------------------------------------------------------

Port Startvlan Endvlan Mvlan

-------------------------------------------------------------------
10GE1/0/2 10 -- 2
10GE1/0/3 10 -- 3
-------------------------------------------------------------------
Total Table(s) : 2
----End
Configuration Files
#
sysname SwitchA
#
#
#
vlan 2
#
vlan 3
#
vlan 10
#
interface 10GE1/0/1
port trunk allow-pass vlan 2 to 3
#
interface 10GE1/0/2
multicast layer-2 bind vlan 10 mvlan 2
#
interface 10GE1/0/3
multicast layer-2 bind vlan 10 mvlan 3
#
return
8.9 Troubleshooting Multicast VLAN Replication
8.9.1 User Hosts in the User VLAN Fail to Receive Multicast Data
Fault Description
After VLAN-based multicast VLAN replication is configured, user hosts in the user VLAN
cannot receive multicast data.
Procedure
l Check whether multicast VLAN replication is correctly configured.
Run the display multicast vlan mvlan [ vlan-id ] command to check whether the user
VLAN is bound to a correct multicast VLAN.

– If the user VLAN is not bound to a correct multicast VLAN, run the multicast vlan
user-vlan command to bind VLANs correctly.
– If the user VLAN is bound to a correct multicast VLAN, check whether other Layer
2 multicast configurations conflict.
The following information shows that user VLANs 100 and 200 are bound to
multicast VLAN 10 correctly.
<HUAWEI> display multicast vlan mvlan 5
Multicast-vlan :
10
User-vlan Number :
2
IGMP snooping state :

Enable
User-vlan Snooping-
state
-----------------------------------------------
100 IGMP
Enable
200 IGMP
Enable
----End

Configuration Guide - IP Multicast 9 Multicast Network Management Configuration
9 Multicast Network Management

Configuration
This chapter describes how to configure the multicast network management function so that
multicast devices can be managed using a network management workstation.
9.1 Overview of Multicast Network Management

9.2 Licensing Requirements and Limitations for Multicast Network Management
9.3 Configuring Multicast Network Management Functions
9.1 Overview of Multicast Network Management

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 devices using a 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 Licensing Requirements and Limitations for Multicast

Network Management
a multicast source.

Multicast network management is a basic software function of the switch. The license for
basic software functions has been loaded and activated before delivery. You do not need to

Required
CE5810EI V100R002C00
CE5850EI V100R001C00
CE5850HI V100R003C00
CE5855EI V100R006C00
CE5880EI V200R005C10
CE6810EI V100R003C00
CE6850EI V100R001C00
CE6850-48S6Q-HI V100R005C00
CE6855HI V200R001C00
CE6856HI V200R002C50
CE6857EI V200R005C10
CE6860EI V200R002C50


Required
CE6865EI V200R005C00
CE6870-48T6CQ-EI V200R002C50
CE6875EI V200R003C00
CE6880EI V200R002C50
CE6881/CE6820/CE6863 V200R005C20
CE7850EI V100R003C00
CE7855EI V200R001C00
CE8850-32CQ-EI V200R002C50
CE8850-64CQ-EI V200R005C00
CE8860EI V100R006C00
CE8861EI/CE8868EI V200R005C10
Feature Limitations
1000 to 2000 1000 seconds
2000 to 8000 2000 seconds
following points:
other services
Item Precautions

Item Precautions
deployed with In V100R006C00 and later versions, an M-LAG set up with

M-LAG standalone switches, SVF systems, or stack systems supports IPv4


9.3 Configuring Multicast Network Management

Functions
Context
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:
l Configure basic multicast functions to ensure normal multicast transmission on the
network.
l Configure basic Simple Network Management Protocol (SNMP) functions to ensure
normal communication with the network management system.
Perform configuration tasks in the listed order.
9.3.1 Enabling Multicast Network Management
Context
Before configuring basic functions of multicast network management, enable multicast
network management on the switch managed by the NMS.
Procedure
Step 2 Run multicast mib
The multicast management information base (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
On a multicast device managed by the network management system (NMS), you can enable
the trap function for a specified module to monitor events of the specified protocol.
Procedure
Step 2 You can choose one or multiple operations to perform:

l Run the snmp-agent trap enable feature-name msdp [ trap-name trap-name ]
command to enable the Multicast Source Discovery Protocol (MSDP) trap function.
By default, the MSDP trap function is disabled.
l Run the snmp-agent trap enable feature-name pim [ trap-name trap-name ]
command to enable the trap function for PIM.
By default, the trap function is disabled for PIM.
l Run the snmp-agent trap enable feature-name pim-std [ trap-name trap-name ]
command to enable the public PIM trap function.
By default, the public PIM trap function is disabled.
Step 3 Run commit
----End
9.3.3 (Optional) Adjusting the Interval for PIM to Send Trap

Messages
Context
After Protocol Independent Multicast (PIM) is enabled on the switches, you can configure
PIM management information base (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 neighbor loss, neighbor addition, receiving invalid Join/
Prune messages, RP-mapping change, interface being elected as the designated router (DR)
and the event of receiving invalid Register messages.
Perform the following steps on the switch managed by the network management system.
Procedure
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.
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
9.3.4 Verifying the Multicast Network Management Function

Configuration
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

CloudEngine 6800 V200R005C20 Configuration Guide - IP Multicast

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CloudEngine 6800 V200R005C20 Configuration Guide - IP Multicast

Încărcat de

Drepturi de autor:

Formate disponibile

CloudEngine 6800 Series Switches

Configuration Guide - IP Multicast

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. i

About This Document

Indicates a potentially hazardous situation

Supplements the important information in

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. ii

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... }* Optional items are grouped in braces and separated by

[ x | y | ... ]* Optional items are grouped in brackets and separated by

&<1-n> The parameter before the & sign can be repeated 1 to n

# A line starting with the # sign is comments.

Interface Numbering Conventions

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. iii

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. iv

Reference Standards and Protocols

Mappings between Product Software Versions and NMS

CloudEngine 6800 series NMS

V200R005C20 Contact technical support personnel.

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. v

Mappings between Product Software Versions and

CloudEngine 6800 series Controller

V200R005C20 Agile Controller-DCN V300R019C00

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. vi

About This Document.....................................................................................................................ii

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. vii

2.8.3 Configuring IGMP Fast Leave.................................................................................................................................. 57

3 IPv4 PIM Configuration............................................................................................................. 87

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. viii

3.7.4.1 Adjusting Time Parameters for Join/Prune Messages.......................................................................................... 139

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. ix

3.8.8 Configuring IPv4 PIM-SM Anycast RP.................................................................................................................. 191

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. x

3.9.8.2 Configuring PIM IPSec........................................................................................................................................ 242

4 MSDP Configuration................................................................................................................ 316

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. xi

4.3.4 MSDP-based Anycast RP........................................................................................................................................ 328

5 IPv4 Multicast Route Management Configuration.............................................................383

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. xii

5.3 Summary of IPv4 Multicast Route Management Configuration Tasks......................................................................397

6 IGMP Snooping Configuration.............................................................................................. 426

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. xiii

6.9.1 Configuring a Multicast Group Policy.................................................................................................................... 459

7 Static Multicast MAC Address Configuration.................................................................... 495

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. xiv

8 Multicast VLAN Replication Configuration........................................................................503

9 Multicast Network Management Configuration.................................................................522

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. xv

1.1 Overview of IP Multicast

1.1 Overview of IP Multicast

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. 1

Figure 1-1 Point-to-multipoint data transmission in unicast and broadcast modes

RouterA RouterD HostA

Source RouterB RouterE

SwitchA SwitchD HostA

Issue 02 (2019-10-15) Copyright © Huawei Technologies Co., Ltd. 2

Figure 1-2 Point-to-multipoint data transmission in multicast mode