Configuration Guide - Multicast (V100R006C00 - 02) PDF

Quidway S9300 Terabit Routing Switch
V100R006C00
Configuration Guide - Multicast
Issue 02
Date 2011-07-15
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2011. 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 the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 02 (2011-07-15) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Configuration Guide - Multicast About This Document
About This Document
Intended Audience
This document describes the multicast service supported by the S9300, including basic
knowledge, protocol implementation, configuration procedures, and configuration examples.
This document guides you through the configuration of the multicast service of the S9300.
This document is intended for:
l Data configuration engineer

l Commissioning engineer
l Network monitoring engineer
l System maintenance engineer
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates a hazard with a high level of risk, which if not

avoided, will result in death or serious injury.
DANGER
Indicates a hazard with a medium or low level of risk, which

if not avoided, could result in minor or moderate injury.
WARNING
Indicates a potentially hazardous situation, which if not

avoided, could result in equipment damage, data loss,
CAUTION
performance degradation, or unexpected results.
TIP Indicates a tip that may help you solve a problem or save
time.
NOTE Provides additional information to emphasize or supplement

important points of the main text.
Issue 02 (2011-07-15) Huawei Proprietary and Confidential ii

Configuration Guide - Multicast About This Document
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by

vertical bars. One item is selected or no item is selected.
{ x | y | ... }* Optional items are grouped in braces and separated by

vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]* Optional items are grouped in brackets and separated by

vertical bars. 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.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 02 (2011-07-15)

The second commercial release has the following updates:
The following contents are modified:
l 2.7.3 (Optional) Configuring Layer 2 Multicast SSM Mapping
l 2.3.5 (Optional) Configuring a Static Router Interface
Changes in Issue 01 (2011-05-20)

Initial commercial release.
Issue 02 (2011-07-15) Huawei Proprietary and Confidential iii

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

1 IP Multicast Configuration Guide.............................................................................................1
1.1 IP Multicast Overview........................................................................................................................................2
1.2 IP Multicast Features Supported by the S9300..................................................................................................2
1.3 IPv4 Multicast Configuration Guide..................................................................................................................2
1.3.1 IPv4 Multicast Addresses..........................................................................................................................2
1.3.2 IPv4 Multicast Protocols...........................................................................................................................3
1.3.3 Typical Configuration Solution.................................................................................................................4
1.3.4 Controlling Multicast Forwarding.............................................................................................................5
1.4 IPv6 Multicast Configuration Guide..................................................................................................................5
1.4.1 IPv6 Multicast Addresses..........................................................................................................................5
1.4.2 IPv6 Multicast Protocols...........................................................................................................................8
1.4.3 Typical Configuration Solution.................................................................................................................9
1.4.4 Controlling Multicast Forwarding.............................................................................................................9
2 IGMP Snooping Configuration................................................................................................10

2.1 IGMP Snooping Overview...............................................................................................................................11
2.2 IGMP Snooping Supported by the S9300........................................................................................................11
2.3 Configuring IGMP Snooping...........................................................................................................................13
2.3.1 Establishing the Configuration Task.......................................................................................................13
2.3.2 Enabling IGMP Snooping.......................................................................................................................14
2.3.3 (Optional) Setting the IGMP Version......................................................................................................14
2.3.4 (Optional) Setting the Forwarding Mode of Multicast Data in a VLAN................................................15
2.3.5 (Optional) Configuring a Static Router Interface....................................................................................16
2.3.6 (Optional) Disabling Dynamic Learning on Interfaces...........................................................................16
2.3.7 (Optional) Configuring IGMP Snooping Querier...................................................................................17
2.3.8 (Optional) Configuring Multicast Policies..............................................................................................18
2.3.9 (Optional) Configuring Prompt Leave for Interfaces..............................................................................19
2.3.10 (Optional) Configuring the S9300 to Respond to Changes of a Layer 2 Network Topology...............20
2.3.11 (Optional) Modifying Parameters of IGMP Snooping in a VLAN.......................................................20
2.3.12 (Optional) Configuring the IGMP Snooping Proxy for the VLAN.......................................................22
2.3.13 (Optional) Filtering Layer 2 Multicast Data on an Interface.................................................................23
2.3.14 Checking the Configuration...................................................................................................................23
Issue 02 (2011-07-15) Huawei Proprietary and Confidential iv

2.4 Configuring Static Layer 2 Multicast...............................................................................................................25

2.4.2 Creating a VLAN and Enabling IGMP Snooping ..................................................................................26
2.4.3 (Optional) Setting the Forwarding Mode of Multicast Data in a VLAN................................................27
2.4.4 Adding an Interface to a VLAN..............................................................................................................27
2.4.5 Adding an Interface to a Multicast Group Statically...............................................................................28
2.4.6 Checking the Configuration.....................................................................................................................28
2.5 Configuring a Static Multicast MAC Address.................................................................................................29
2.5.2 Configuring a Static Multicast MAC Address........................................................................................30
2.6 Configuring Layer 2 Multicast CAC................................................................................................................31
2.6.2 Limiting the Number of Multicast Groups of a VLAN, a Layer 2 Interface, or an Interface in a VLAN
..........................................................................................................................................................................33
2.6.3 Limiting the Number of Multicast Groups in a Channel for a VLAN, an Interface, or an Interface in a
VLAN...............................................................................................................................................................34
2.6.4 Configuring Channels on a VLAN..........................................................................................................35
2.7 Configuring Layer 2 Multicast SSM Mapping.................................................................................................37
2.7.2 (Optional) Configuring an SSM Group Policy........................................................................................38
2.7.3 (Optional) Configuring Layer 2 Multicast SSM Mapping......................................................................38
2.8 Maintaining Layer 2 Multicast.........................................................................................................................40
2.8.1 Clearing Static Entries in a Multicast Forwarding Table........................................................................40
2.8.2 Clearing Multicast Forwarding Entries...................................................................................................41
2.8.3 Clearing the Statistics on IGMP Snooping..............................................................................................41
2.8.4 Debugging IGMP Snooping....................................................................................................................42
2.8.5 Debugging Layer 2 Multicast CAC.........................................................................................................42
2.9 Configuration examples....................................................................................................................................42
2.9.1 Example for Configuring IGMP Snooping.............................................................................................43
2.9.2 Example for Configuring Layer 2 Multicast CAC for a VLAN..............................................................45
2.9.3 Example for Configuring IGMP Snooping SSM Mapping.....................................................................49
3 Multicast VLAN Replication Configuration..........................................................................53

3.1 Multicast VLAN Replication Overview...........................................................................................................54
3.2 Multicast VLAN Replication Supported by the S9300....................................................................................54
3.3 Configuring Multicast VLAN Replication Based on User VLANs.................................................................56
3.3.2 Configuring Multicast VLAN Replication Based on User VLANs........................................................57
3.3.3 Adding Interfaces to VLANs...................................................................................................................58
3.4 Configuring Multicast VLAN Replication Based on Interfaces.......................................................................59
Issue 02 (2011-07-15) Huawei Proprietary and Confidential v


3.4.2 Creating a Multicast VLAN....................................................................................................................60
3.4.3 Binding User VLANs to a Multicast VLAN on an Interface..................................................................60
3.4.4 Adding Interfaces to VLANs...................................................................................................................61
3.5 Configuration Examples...................................................................................................................................61
3.5.1 Example for Configuring Multicast VLAN Replication Based on User VLANs...................................62
3.5.2 Example for Configuring Multicast VLAN Replication Based on Interfaces.........................................64
4 IGMP Configuration...................................................................................................................68
4.1 Introduction to IGMP.......................................................................................................................................69
4.2 IGMP Features Supported by the S9300..........................................................................................................69
4.3 Configuring Basic IGMP Functions.................................................................................................................70
4.3.2 Enabling IP Multicast..............................................................................................................................71
4.3.3 Enabling the IGMP Function...................................................................................................................72
4.3.4 (Optional) Specifying the IGMP Version................................................................................................72
4.3.5 (Optional) Configuring a Static IGMP Group.........................................................................................73
4.3.6 (Optional) Configuring an IGMP Multicast Group Policy......................................................................74
4.4 Setting the Parameters of IGMP Features........................................................................................................75
4.4.2 Configuring IGMP Message Options......................................................................................................76
4.4.3 Configuring the IGMPv1 Querier............................................................................................................78
4.4.4 Configuring the IGMPv2 or IGMPv3 Querier........................................................................................79
4.4.5 Configuring IGMP Prompt Leave...........................................................................................................81
4.5 Configuring SSM Mapping..............................................................................................................................83
4.5.2 Enabling SSM Mapping..........................................................................................................................84
4.5.3 Configuring the SSM Mapping Policy....................................................................................................84
4.6 Configuration IGMP Limit Function................................................................................................................86
4.6.2 (Optional) Configuring the Maximum Number of Global IGMP Group Memberships.........................86
4.6.3 (Optional) Setting the Maximum Number of Global IGMP Entries for an Instance..............................87
4.6.4 (Optional) Configuring the Maximum Number of IGMP Group Memberships on an Interface............87
4.7 Maintaining IGMP............................................................................................................................................88
4.7.1 Clearing the Information About an IGMP Group...................................................................................88
4.7.2 Monitoring the Running Status of IGMP................................................................................................88
4.7.3 Debugging IGMP....................................................................................................................................89
4.8 Configuration Examples...................................................................................................................................89
Issue 02 (2011-07-15) Huawei Proprietary and Confidential vi

4.8.1 Example for Configuring Basic IGMP Functions...................................................................................89

4.8.2 Example for Configuring SSM Mapping................................................................................................93
4.8.3 Example for Configuring IGMP Limit....................................................................................................99
5 PIM-DM (IPv4) Configuration................................................................................................104

5.1 PIM-DM Overview.........................................................................................................................................106
5.2 PIM-DM Features Supported by the S9300...................................................................................................107
5.3 Configuring Basic PIM-DM Functions..........................................................................................................108
5.3.1 Establishing the Configuration Task.....................................................................................................108
5.3.2 Enabling IPv4 Multicast Routing..........................................................................................................109
5.3.3 Enabling PIM-DM.................................................................................................................................109
5.4 Adjusting Control Parameters of a Multicast Source.....................................................................................111
5.4.2 Configuring the Lifetime of a Source....................................................................................................112
5.4.3 Configuring Filtering Rules Based on Source Addresses.....................................................................113
5.5 Adjusting Control Parameters for Maintaining Neighbor Relationships.......................................................114
5.5.2 Configuring the Interval for Sending Hello Messages..........................................................................115
5.5.3 Configuring the Timeout Period of a Neighbor.....................................................................................116
5.5.4 Refusing to Receive the Hello Message Without the Generation ID Option........................................117
5.5.5 Configuring PIM Neighbor Filtering.....................................................................................................118
5.6 Adjusting Control Parameters for Prune........................................................................................................119
5.6.2 Configuring the Period for an Interface to Keep the Prune State..........................................................120
5.6.3 Configuring the Delay for Transmitting Prune Messages in a LAN.....................................................121
5.6.4 Configuring the Interval for Overriding the Prune Action....................................................................122
5.7 Adjusting Control Parameters for State-Refresh............................................................................................123
5.7.2 Disabling State-Refresh.........................................................................................................................124
5.7.3 Configuring the Interval for Sending State-Refresh Messages.............................................................125
5.7.4 Configuring the Period for Receiving the Next State-Refresh Message...............................................126
5.7.5 Configuring the TTL Value Carried in a State-Refresh Message.........................................................126
5.8 Adjusting Control Parameters for Graft.........................................................................................................128
5.8.2 Configuring the Interval for Retransmitting Graft Messages................................................................128
5.9 Adjusting Control Parameters for Assert........................................................................................................130
Issue 02 (2011-07-15) Huawei Proprietary and Confidential vii

5.9.2 Configuring the Period for Keeping the Assert State............................................................................131

5.10 Configuring PIM Silent................................................................................................................................132
5.10.1 Establishing the Configuration Task...................................................................................................133
5.10.2 Configuring PIM Silent.......................................................................................................................134
5.10.3 Checking the Configuration.................................................................................................................134
5.11 Maintaining PIM-DM (IPv4)........................................................................................................................135
5.11.1 Clearing Statistics of PIM Control Messages......................................................................................135
5.11.2 Monitoring the Running Status of PIM...............................................................................................136
5.11.3 Debugging PIM...................................................................................................................................137
5.12 Configuration Example.................................................................................................................................138
5.12.1 Example for Configuring the PIM-DM Network................................................................................138
6 PIM-SM (IPv4) Configuration................................................................................................144

6.1 PIM-SM Overview.........................................................................................................................................146
6.2 PIM-SM Features Supported by the S9300....................................................................................................147
6.3 Configuring Basic PIM-SM Functions...........................................................................................................149
6.3.2 Enabling IP Multicast Routing..............................................................................................................150
6.3.3 Enabling Basic PIM-SM Functions.......................................................................................................151
6.3.4 (Optional) Configuring a Static RP.......................................................................................................152
6.3.5 (Optional) Configuring a Dynamic RP..................................................................................................153
6.3.6 (Optional) Configuring the SSM Group Address Range.......................................................................154
6.4 Adjusting Control Parameters for a Multicast Source....................................................................................156
6.4.2 Configuring the Lifetime of a Source....................................................................................................157
6.4.3 Configuring Filtering Rules Based on Source Addresses.....................................................................157
6.5 Adjusting Control Parameters of the C-RP and C-BSR.................................................................................158
6.5.2 Adjusting C-RP Parameters...................................................................................................................159
6.5.3 Adjusting C-BSR Parameters................................................................................................................160
6.5.4 Configuring the BSR Boundary............................................................................................................161
6.5.5 (Optional) Configuring the BSR Address Range..................................................................................162
6.5.6 (Optional) Configuring the Range of Valid C-RP Addresses...............................................................162
6.6 Configuring a BSR Administrative Domain..................................................................................................163
6.6.2 Enabling a BSR Administrative Domain...............................................................................................165
6.6.3 Configuring the Boundary of a BSR Administrative Domain..............................................................165
6.6.4 Adjusting C-BSR Parameters................................................................................................................166
Issue 02 (2011-07-15) Huawei Proprietary and Confidential viii

6.7 Adjusting Control Parameters for Establishing the Neighbor Relationship...................................................167

6.7.2 Configuring Control Parameters for Establishing the Neighbor Relationship......................................168
6.7.3 Configuring Control Parameters for Electing a DR..............................................................................170
6.7.4 Enabling the Function of Tracking a Downstream Neighbor................................................................171
6.7.5 Configuring PIM Neighbor Filtering.....................................................................................................172
6.8 Adjusting Control Parameters for Source Registering...................................................................................173
6.8.2 Configuring PIM-SM Register Messages..............................................................................................174
6.8.3 Configuring PIM-SM Register Suppression..........................................................................................175
6.9 Adjusting Control Parameters for Forwarding...............................................................................................175
6.9.2 Configuring Control Parameters for Keeping the Forwarding State.....................................................177
6.9.3 Configuring Control Parameters for Prune............................................................................................178
6.9.4 Configuring Join Information Filtering.................................................................................................179
6.9.5 Configuring Neighbor Check................................................................................................................180
6.10 Adjusting Control Parameters for Assert......................................................................................................181
6.10.2 Configuring the Period for Keeping the Assert State..........................................................................182
6.11 Configuring the SPT Switchover..................................................................................................................184
6.11.2 (Optional) Configuring the Interval for Checking the Forwarding Rate of Multicast Data................185
6.12 Configuring PIM BFD..................................................................................................................................186
6.12.2 Configuring PIM BFD.........................................................................................................................187
6.12.3 (Optional) Adjusting BFD Parameters................................................................................................188
6.13 Configuring PIM GR....................................................................................................................................189
6.13.2 Configuring PIM GR...........................................................................................................................190
6.14 Configuring PIM Silent................................................................................................................................191
6.14.2 Configuring PIM Silent.......................................................................................................................192
6.15 Maintaining PIM-SM (IPv4)........................................................................................................................194
6.15.1 Clearing Statistics of PIM Control Messages......................................................................................194
Issue 02 (2011-07-15) Huawei Proprietary and Confidential ix

6.15.2 Clearing the PIM Status of the Specified Downstream Interfaces of PIM Entries.............................194
6.15.3 Monitoring the Running Status of PIM-SM........................................................................................195
6.15.4 Debugging PIM...................................................................................................................................196
6.16 Configuration Examples...............................................................................................................................197
6.16.1 Example for Configuring the PIM-SM Network.................................................................................197
6.16.2 Example for Configuring SPT Switchover in PIM-SM Domain........................................................207
6.16.3 Example for Configuring PIM BFD....................................................................................................212
6.16.4 Example for Configuring PIM GR......................................................................................................215
7 MSDP Configuration................................................................................................................223
7.1 MSDP Overview.............................................................................................................................................225
7.2 MSDP Features Supported by the S9300.......................................................................................................225
7.3 Configuring PIM-SM Inter-domain Multicast...............................................................................................227
7.3.2 Configuring Intra-AS MSDP Peers.......................................................................................................228
7.3.3 Configuring Inter-AS MSDP Peers on MBGP Peers............................................................................230
7.3.4 Configuring Static RPF Peers................................................................................................................231
7.4 Configuring an Anycast RP in a PIM-SM Domain........................................................................................233
7.4.2 Configuring the Interface Address of an RP.........................................................................................234
7.4.3 Configuring a C-RP...............................................................................................................................235
7.4.4 Statically Configuring an RP.................................................................................................................235
7.4.5 Configuring an MSDP Peer...................................................................................................................236
7.4.6 Specifying the Logical RP Address for an SA Message.......................................................................237
7.5 Managing MSDP Peer Connections...............................................................................................................239
7.5.2 Controlling the Sessions Between MSDP Peers....................................................................................240
7.5.3 Adjusting the interval for Retrying Setting up an MSDP Peer Connection..........................................240
7.6 Configuring SA Cache....................................................................................................................................241
7.6.2 Configuring the Maximum Number of (S, G) Entries in the Cache......................................................242
7.6.3 Disabling the SA Cache Function.........................................................................................................243
7.7 Configuring the SA Request...........................................................................................................................244
7.7.2 Configuring "Sending SA Request Messages" on the Local switch.....................................................245
7.7.3 (Optional) Configuring the Filtering Rules for Receiving SA Request Messages................................246
7.7.4 Check the Configuration........................................................................................................................246
7.8 Transmitting Burst Multicast Data Between Domains...................................................................................247
Issue 02 (2011-07-15) Huawei Proprietary and Confidential x

7.8.2 Encapsulating a Multicast Data Packet in an SA message....................................................................248

7.8.3 (Optional) Setting the TTL Threshold for Forwarding an SA Message Containing a Multicast Data Packet
........................................................................................................................................................................249
7.9 Configuring the Filtering Rules for SA Messages..........................................................................................251
7.9.2 Setting Rules for Creating an SA Message...........................................................................................252
7.9.3 Setting Rules for Receiving an SA Message.........................................................................................253
7.9.4 Setting Rules for Forwarding an SA Message.......................................................................................253
7.10 Configuring MSDP Authentication..............................................................................................................255
7.10.2 Configuring MSDP MD5 Authentication............................................................................................256
7.10.3 Configuring MSDP Key-Chain Authentication..................................................................................257
7.11 Maintaining MSDP.......................................................................................................................................258
7.11.1 Clearing Statistics of MSDP Peers......................................................................................................258
7.11.2 Clearing (S, G) Information in SA Cache...........................................................................................259
7.11.3 Monitoring the Running Status of MSDP...........................................................................................259
7.11.4 Debugging MSDP................................................................................................................................260
7.12.1 Example for Configuring Basic MSDP Functions..............................................................................261
7.12.2 Example for Configuring Inter-AS Multicast by Using Static RPF Peers..........................................270
7.12.3 Example for Configuring Anycast RP.................................................................................................277
8 IPv4 Multicast VPN Configuration........................................................................................284

8.1 Overview of IPv4 Multicast VPN..................................................................................................................285
8.2 IPv4 Multicast VPN Supported by the S9300................................................................................................286
8.3 Configuring Basic MD VPN Functions..........................................................................................................287
8.3.2 Enabling IP Multicast Routing..............................................................................................................288
8.3.3 Configuring the Eth-Trunk as a Multicast Loopback Interface.............................................................288
8.3.4 Configuring Share-Group and Binding an MTI....................................................................................289
8.3.5 Configuring an MTI...............................................................................................................................290
8.4 Configuring Switch-MDT Switchover...........................................................................................................291
8.4.2 (Optional) Setting Switching Parameters of Switch-MDT....................................................................292
8.5 Maintaining IPv4 Multicast VPN...................................................................................................................293
8.5.1 Monitoring the Running Status of IPv4 Multicast VPN........................................................................293
8.5.2 Debugging IPv4 Multicast VPN............................................................................................................294
8.5.3 Controlling the Output of Logs.............................................................................................................294
Issue 02 (2011-07-15) Huawei Proprietary and Confidential xi

8.6 Configuration Examples.................................................................................................................................295

8.6.1 Example for Configuring a Single-AS MD VPN..................................................................................295
9 IPv4 Multicast Routing Management....................................................................................319

9.1 Overview of IPv4 Multicast Routing Management........................................................................................321
9.2 IPv4 Multicast Routing Management Features Supported by the S9300.......................................................321
9.3 Configuring a Static Multicast Route.............................................................................................................323
9.3.2 Configuring a Static Multicast Route....................................................................................................324
9.4 Configuring the Multicast Routing Policy......................................................................................................326
9.4.2 Configuring Longest Match of Multicast Route....................................................................................326
9.4.3 Configuring Multicast Load Splitting....................................................................................................327
9.4.4 Configuring a Multicast Load Splitting Weight....................................................................................330
9.5 Configuring the Multicast Forwarding Scope................................................................................................331
9.5.1 Establish the Configuration Task..........................................................................................................331
9.5.2 Configuring the Multicast Forwarding Boundary.................................................................................332
9.6 Configuring Control Parameters of the Multicast Forwarding Table.............................................................333
9.6.2 Setting the Maximum Number of Entries in Multicast Forwarding Table............................................334
9.6.3 Setting the Maximum Number of Downstream Nodes of Multicast Forwarding Entry.......................335
9.7 Maintaining the Multicast Policy...................................................................................................................336
9.7.1 Testing Multicast Routing.....................................................................................................................336
9.7.2 Check RPF Paths and Multicast Paths...................................................................................................337
9.7.3 Clearing Multicast Routing and Forwarding Entries.............................................................................338
9.7.4 Monitoring the Status of Multicast Routing and Forwarding................................................................338
9.7.5 Debugging Multicast Routing and Forwarding.....................................................................................339
9.8 Configuration Examples.................................................................................................................................340
9.8.1 Example for Changing Static Multicast Routes to RPF Routes............................................................340
9.8.2 Example for Connecting RPF Routes Through Static Multicast Routes...............................................344
9.8.3 Example for Configuring Multicast Load Splitting...............................................................................349
10 MLD Configuration................................................................................................................357
10.1 MLD Overview.............................................................................................................................................359
10.2 MLD Features Supported by the S9300.......................................................................................................359
10.3 Configuring Basic MLD Functions..............................................................................................................360
10.3.2 Enabling IPv6 Multicast Routing........................................................................................................361
10.3.3 Enabling MLD.....................................................................................................................................361
10.3.4 (Optional) Configuring the MLD Version...........................................................................................362
Issue 02 (2011-07-15) Huawei Proprietary and Confidential xii

10.3.5 (Optional) Configuring an Interface to Statically Join a Group..........................................................362

10.3.6 (Optional) Configuring the Range of Groups an Interface Can Join...................................................363
10.4 Configuring Options of an MLD Packet......................................................................................................364
10.4.2 Configuring the Router-Alert Option of an MLD Packet....................................................................365
10.5 Configuring MLD Query Control.................................................................................................................366
10.5.2 (Optional) Configuring MLD Query and Response............................................................................367
10.6 Configuring SSM Mapping..........................................................................................................................370
10.6.2 Enabling SSM Mapping......................................................................................................................371
10.6.3 Configuring the Static SSM Mapping Policy......................................................................................371
10.7 Configuration MLD Limit Function.............................................................................................................373
10.7.2 Configuring the Maximum Number of Global MLD Group Memberships........................................374
10.7.3 Configuring the Maximum Number of Global MLD Entries in a Single Instance.............................374
10.7.4 Configuring the Maximum Number of MLD Group Memberships on an Interface...........................375
10.8 Maintaining MLD.........................................................................................................................................376
10.8.1 Clearing Information about MLD Groups...........................................................................................376
10.8.2 Monitoring the Running Status of MLD.............................................................................................377
10.8.3 Debugging MLD..................................................................................................................................378
10.9 Configuration Example.................................................................................................................................378
10.9.1 Example for Configuring Basic MLD Functions................................................................................378
10.9.2 Example for Configuring MLD Limit.................................................................................................382
11 MLD Snooping Configuration..............................................................................................387

11.1 Overview of MLD Snooping........................................................................................................................389
11.2 MLD Snooping Features Supported by the S9300.......................................................................................389
11.3 Enabling MLD Snooping..............................................................................................................................390
11.3.2 Enabling MLD snooping on the S9300...............................................................................................391
11.3.3 Enabling MLD Snooping in a VLAN..................................................................................................392
11.3.4 (Optional) Adding an Interface to a Multicast Group Statically.........................................................392
11.3.5 (Optional) Configuring an Interface as a Static Router Interface........................................................393
11.3.6 (Optional) Configuring the MLD Version...........................................................................................393
11.4 Configuring a Multicast Group Policy for a VLAN.....................................................................................394
Issue 02 (2011-07-15) Huawei Proprietary and Confidential xiii

11.4.2 Configuring a Multicast Group Policy................................................................................................395

11.5 Configuring Prompt Leave of Interfaces......................................................................................................396
11.5.2 Configuring Prompt Leave of Interfaces.............................................................................................396
11.6 Configuring the MLD Snooping Querier.....................................................................................................397
11.6.2 Enabling the MLD Snooping Querier.................................................................................................398
11.6.3 Setting the MLD Snooping Query Interval and Response Interval.....................................................399
11.6.4 Setting the Source IPv6 Address of MLD Query Messages...............................................................399
11.7 (Optional) Modifying Parameters of MLD Snooping..................................................................................400
11.7.2 (Optional) Setting the Aging Time of the Router Interface.................................................................401
11.7.3 (Optional) Setting Parameters Related to the Aging Time of Member Interfaces..............................402
11.7.4 (Optional) Configuring the Router Alert Option in MLD Messages..................................................403
11.7.5 (Optional) Enabling the MLD Snooping Module to Respond to Changes of the Layer 2 Network
Topology.........................................................................................................................................................403
11.7.6 (Optional) Setting the Duration for Suppressing the Same MLD Messages.......................................404
11.8 Maintaining MLD Snooping........................................................................................................................405
11.8.1 Clearing MLD Snooping Entries.........................................................................................................405
11.8.2 Clearing the Statistics on MLD Snooping...........................................................................................406
11.8.3 Debugging MLD Snooping.................................................................................................................406
11.9.1 Example for Configuring a Multicast Group Policy...........................................................................406
11.9.2 Example for Configuring Prompt Leave of Interfaces in a VLAN.....................................................409
11.9.3 Example for Configuring a Static Router Interface.............................................................................411
11.9.4 Example for Enabling the MLD Snooping Module to Respond to Changes of the Layer 2 Network
Topology.........................................................................................................................................................413
12 PIM-DM (IPv6) Configuration..............................................................................................417

12.1 PIM-IPv6 Overview.....................................................................................................................................419
12.2 PIM-DM Features Supported by the S9300.................................................................................................419
12.3 Configuring Basic PIM-DM (IPv6) Functions.............................................................................................420
12.3.3 Enabling Basic PIM-DM (IPv6) Functions.........................................................................................421
12.4 Adjusting Control Parameters of a Source...................................................................................................423
12.4.2 Configuring the Keepalive Period of a Source....................................................................................423
12.4.3 Configuring Filtering Rules Based on Source Addresses...................................................................424
Issue 02 (2011-07-15) Huawei Proprietary and Confidential xiv


12.5 Adjusting Control Parameters for Maintaining Neighbors...........................................................................425
12.5.2 Configuring the Interval for Sending Hello Messages........................................................................426
12.5.3 Configuring the Timeout Period of a Neighbor...................................................................................427
12.5.4 Refusing to Receive the Hello Message Without the Generation ID Option......................................428
12.5.5 Configuring PIM Neighbor Filtering...................................................................................................429
12.6 Adjusting Control Parameters for Prune......................................................................................................430
12.6.2 Configuring the Period for an Interface to Keep the Prune State........................................................431
12.6.3 Configuring the Delay for Transmitting Prune Messages in a LAN...................................................432
12.6.4 Configuring the Interval for Overriding the Prune Action..................................................................433
12.7 Adjusting Control Parameters for State-Refresh..........................................................................................434
12.7.1 Estalishing the Configuration Task.....................................................................................................434
12.7.2 Disabling State-Refresh.......................................................................................................................435
12.7.3 Configuring the Interval for Sending State-Refresh Messages...........................................................436
12.7.4 Configuring the Period for Receiving the Next State-Refresh Message.............................................436
12.7.5 Configuring the TTL Value of a State-Refresh Message....................................................................437
12.8 Adjusting Control Messages for Graft..........................................................................................................438
12.8.2 Setting the Interval for Retransmitting Graft Messages......................................................................439
12.9 Adjusting Control Messages for Assert........................................................................................................440
12.10 Configuring PIM-IPv6 Silent.....................................................................................................................442
12.10.1 Establishing the Configuration Task.................................................................................................443
12.10.2 Configuring PIM-IPv6 Silent............................................................................................................444
12.10.3 Checking the Configuration...............................................................................................................444
12.11 Maintaining PIM-DM.................................................................................................................................445
12.11.1 Clearing Statistics of PIM Control Messages....................................................................................445
12.11.2 Monitoring Running Status of PIM-DM...........................................................................................445
12.11.3 Debugging PIM-IPv6........................................................................................................................446
12.12 Configuration Example...............................................................................................................................447
12.12.1 Example for Configuring the IPv6 PIM-DM Network.....................................................................447
13 PIM-SM (IPv6) Configuration..............................................................................................452

13.1 PIM-IPv6 Overview.....................................................................................................................................454
13.2 PIM-SM Features Supported by the S9300..................................................................................................454
Issue 02 (2011-07-15) Huawei Proprietary and Confidential xv

13.3 Configuring Basic PIM-SM (IPv6) Functions..............................................................................................456

13.3.3 Enabling Basic PIM-SM (IPv6) Functions..........................................................................................458
13.3.4 (Optional) Configuring an Embedded-RP...........................................................................................459
13.3.5 (Optional) Configuring a Static RP.....................................................................................................460
13.3.6 (Optional) Configuring a Dynamic RP................................................................................................461
13.3.7 (Optional) Configuring the SSM Group Address Range.....................................................................462
13.4 Adjusting Control Parameters of a Source...................................................................................................464
13.4.2 Configuring the Keepalive Period of a Source....................................................................................464
13.4.3 Configuring Filtering Rules Based on Source Addresses...................................................................465
13.5 Adjusting Control Parameters of a C-RP and a C-BSR...............................................................................466
13.5.2 Adjusting Control Parameters of a C-RP............................................................................................467
13.5.3 Adjusting Control Parameters of a C-BSR..........................................................................................468
13.5.4 Configuring the BSR Service Boundary.............................................................................................469
13.5.5 (Optional) Configuring the Range of Legal BSR addresses................................................................470
13.5.6 (Optional) Configuring the Range of Legal C-RP Addresses.............................................................470
13.6 Adjusting Control Parameters for Maintaining Neighbors...........................................................................471
13.6.2 Configuring Control Parameters for Maintaining PIM Neighbors......................................................472
13.6.3 Configuring Control Parameters for Electing a DR............................................................................474
13.6.4 Enabling the Function of Tracking a Downstream Neighbor..............................................................475
13.6.5 Configuring PIM Neighbor Filtering...................................................................................................476
13.7 Adjusting Control Parameters of Source Registering...................................................................................477
13.7.2 Configuring Rules for Filtering PIM-SM (IPv6) Register Messages..................................................478
13.7.3 Configuring PIM-SM (IPv6) Registering Suppression.......................................................................479
13.8 Adjusting Control Parameters for Forwarding.............................................................................................479
13.8.2 Configuring Control Parameters for Keeping the Forwarding Relationship.......................................481
13.8.3 Configuring Control Parameters for Prune..........................................................................................482
13.8.4 Configuring Join Information Filtering...............................................................................................483
13.8.5 Configuring Neighbor Check..............................................................................................................484
13.9 Configuring Control Parameters for Assert..................................................................................................485
Issue 02 (2011-07-15) Huawei Proprietary and Confidential xvi


13.10 Adjusting Control Parameters for the SPT Switchover..............................................................................487
13.10.2 (Optional) Adjusting Conditions of the SPT Switchover..................................................................488
13.10.3 (Optional) Configuring the Interval for Checking the Forwarding Rate of Multicast Data..............489
13.11 Configuring PIM GR (IPv6).......................................................................................................................490
13.11.2 Configuring PIM GR (IPv6)..............................................................................................................491
13.12 Configuring PIM-IPv6 Silent.....................................................................................................................492
13.12.2 Configuring PIM-IPv6 Silent............................................................................................................493
13.13 Maintaining PIM-SM.................................................................................................................................494
13.13.1 Clearing Statistics of PIM-IPv6 Control Messages...........................................................................494
13.13.2 Clearing the PIM Status of the Specified Downstream Interfaces of PIM Entries...........................495
13.13.3 Monitoring the Running Status of PIM-SM......................................................................................495
13.13.4 Debugging PIM-IPv6........................................................................................................................496
13.14 Configuration Example...............................................................................................................................497
13.14.1 Example for Configuring the IPv6 PIM-SM Network......................................................................497
13.14.2 Example for Configuring PIM GR (IPv6).........................................................................................505
14 IPv6 Multicast Routing Management..................................................................................513

14.1 Overview of IPv6 Multicast Routing Management......................................................................................515
14.2 IPv6 Multicast Routing Management Features Supported by the S9300.....................................................515
14.3 Configuring the IPv6 Multicast Routing Policy...........................................................................................516
14.3.2 Configuring IPv6 Multicast Load Splitting.........................................................................................517
14.3.3 Configuring an IPv6 Multicast Load Splitting Weight.......................................................................518
14.4 Limiting the Range of Multicast Forwarding...............................................................................................519
14.4.2 Configuring the IPv6 Multicast Forwarding Boundary on an Interface..............................................520
14.5 Configuring Control Parameters of the IPv6 Multicast Forwarding Table..................................................521
14.5.2 Configuring the Maximum Number of Entries in the IPv6 Multicast Forwarding Table...................522
14.5.3 Configuring the Maximum Number of Downstream Nodes of a Single Forwarding Entry...............523
14.6 Maintaining IPv6 Multicast Routing Management......................................................................................523
Issue 02 (2011-07-15) Huawei Proprietary and Confidential xvii

14.6.1 Clearing IPv6 Multicast Forwarding Entries and Routing Entries......................................................524

14.6.2 Monitoring the Running Status of IPv6 Multicast Forwarding and Routing......................................524
14.6.3 Debugging IPv6 Multicast Forwarding and Routing..........................................................................525
14.7.1 Example for Configuring IPv6 Multicast Load Splitting....................................................................525
Issue 02 (2011-07-15) Huawei Proprietary and Confidential xviii

Configuration Guide - Multicast 1 IP Multicast Configuration Guide
1 IP Multicast Configuration Guide
About This Chapter
The system supports the construction of multicast services through multicast protocols in IPv4
and IPv6 networks. In addition, the typical configuration solutions of multicast networks are
provided.
1.1 IP Multicast Overview

1.2 IP Multicast Features Supported by the S9300
1.3 IPv4 Multicast Configuration Guide
This section describes multicast addresses, protocols, and typical configuration solutions in IPv4
networks.
This section describes multicast addresses, protocols, and typical configuration solutions on an
IPv6 network.
Issue 02 (2011-07-15) Huawei Proprietary and Confidential 1

1.1 IP Multicast Overview

Multicast is a Point to Multi-Point (P2MP) data transmission mode. During data transmission,
multicast can ensure the security of information. Multicast consumes limited network
bandwidth.
The multicast technology applied to IPv4 and IPv6 is called IP multicast.
The Internet services implemented through IP multicast include IPTV, Video and Audio
Conferences, e-learning, and remote medicine.
1.2 IP Multicast Features Supported by the S9300

In the S9300, IPv4 networks and IPv6 networks can support multicast services, but networks
that run IPv4 and IPv6 simultaneously do not support multicast services.

This section describes multicast addresses, protocols, and typical configuration solutions in IPv4
networks.
1.3.1 IPv4 Multicast Addresses

The IPv4 multicast addresses range from 224.0.0.0 to 239.255.255.255. Table 1-1 shows the
ranges of various IPv4 multicast addresses.
The multicast group address available for multicast data services ranges from 224.0.1.0 to
239.255.255.255. Any host (or other receiving device) that joins a multicast group within this
range becomes a member of the group, and can identify and receive IP packets with the IP
multicast address as the destination address. The members of a group can be distributed at any
position in the network. The hosts can join or leave a multicast group at any time.
Table 1-1 Class D addresses
Class D Address Range Description
224.0.0.0 to 224.0.0.255 Indicates the reserved group addresses for local links. The
addresses are reserved by Internet Assigned Number
Authority (IANA) for routing protocols, and are called
permanent multicast group addresses. The addresses are
used to identify a group of specific network devices rather
than being used for multicast forwarding.
224.0.1.0 to 231.255.255.255 Indicates Any-Source Multicast (ASM) addresses. The

233.0.0.0 to 238.255.255.255 addresses are valid in the entire network.
232.0.0.0 to 232.255.255.255 Indicates Source-Specific Multicast (SSM) addresses.

This is the default SSM group address scope, and is valid
in the entire network.

Class D Address Range Description
239.0.0.0 to 239.255.255.255 Indicates administration multicast addresses. The default

range of BSR administrative domain group addresses is
valid only in the local BSR administration domain. The
addresses are private addresses. You can configure the
same address in different BSR administration domains.
1.3.2 IPv4 Multicast Protocols

To implement a complete set of IPv4 multicast services, various multicast protocols deployed
in the network need to cooperate with each other, as shown in Figure 1-1.
Figure 1-1 Location of each IPv4 multicast protocol
IPv4 Network IPv4 Network

AS1 AS2
Source
PIM PIM
MSDP
IGMP IGMP
User User

Table 1-2 Multicast protocols
Applied Location Objectives Multicast Protocol
Between hosts and Connecting hosts to a multicast Internet Group

multicast switches network: Management Protocol
l Ensure that the members can (IGMP)
dynamically join and leave a
group at the host side.
l Manage and maintain the
member relationship at the switch
side and exchange information
with the upper-layer multicast
routing protocols.
Between intra-domain Multicast routing and forwarding: Protocol Independent

multicast switches l Create multicast routes on Multicast (PIM), including
demand. Protocol Independent
Multicast-Dense Mode
l Respond to the changes of the (PIM-DM) and Protocol
network topology and maintain Independent Multicast-
the multicast routing table. Sparse Mode (PIM-SM)
l Forward packets according to the
routing table.
Between inter-domain Sharing information about inter- Multicast Source

multicast switches domain multicast sources: Discovery Protocol
l Switches in the domain where the (MSDP)
source resides transmit the local
source information to switches in
other domains.
l Switches in different domains
transmit the source information.
1.3.3 Typical Configuration Solution
CAUTION
Customize configuration solutions according to the actual network conditions and service
requirements. The configuration solution in this section functions only as a reference.
The network environments are classified into two types, which need different configuration
solutions. For details, refer to the Quidway S9300 Terabit Routing Switch Configuration Guide
- Multicast.
NOTE
Ensure that unicast routes work normally in the network before configuring IP multicast.

Small-Scale Network
A small-scale network, such as a test network, is suitable to implement multicast data
transmission in a Local Area Network (LAN), and does not interconnect with the Internet.
Perform the following configurations:
1. Enable multicast on all S9300s in the network.

2. Enable PIM-DM on all interfaces of the S9300s.
3. Enable IGMP on the S9300 interface connected to hosts.
4. If multicast needs to be deployed in a VPN, perform the preceding configurations in the
private network and public network respectively, and configure the Multicast Domain
(MD) on PEs.
Large-Scale Network
A large-scale network is suitable to transmit multicast services on an ISP network, and
interconnects with the Internet.
1. Enable multicast on all S9300s in the network.

2. Enable PIM-SM on all interfaces of the S9300s.
3. Enable IGMP on the S9300 interface connected to hosts.
4. Configure an RP, specify a static RP, or elect an RP from C-RPs.
5. Divide a network into PIM-SM domains.
6. Configure MSDP in the PIM-SM domain and implement the anycast RP.
7. Configure MSDP between PIM-SM domains. Generally, MSDP cooperates with MBGP.
1.3.4 Controlling Multicast Forwarding

IP multicast guides the forwarding of multicast packets by using the multicast routing table and
forwarding table. You can adjust the transmission path of multicast data by configuring the
Reverse Path Forwarding (RPF) routing policy, and limit multicast forwarding by configuring
the forwarding policy and the capacity of the forwarding table.
For details, refer to the chapter 9 IPv4 Multicast Routing Management in the Quidway
S9300 Terabit Routing Switch Configuration Guide - Multicast.

This section describes multicast addresses, protocols, and typical configuration solutions on an
IPv6 network.
1.4.1 IPv6 Multicast Addresses

Figure 1-2 shows the format of an IPv6 multicast address.

Figure 1-2 Format of an IPv6 multicast address

0 7 11 15 31
FF flags scope
reserved (80bit)
group ID (32bit)
The meaning of each field is as follows:

l The IPv6 multicast address begins with FF.
l Flags (four-bit): The meaning of the last bit is as follows:
– 0: indicates that the address is a well-known multicast address defined by IANA.
– 1 or 2: indicates multicast addresses within the ASM group address range.
– 3: indicates multicast addresses within the SSM group address range.
– Other: indicates unallocated ones. It can also indicate the multicast addresses within the
ASM group address range.
l Scope (four-bit): indicates that the multicast group contains only the nodes of the same
local network, the same site, and the same organization. The meaning of each field is as
follows:
– 0: reserved
– 1: node/interface-local scope
– 2: link-local scope
– 3: reserved
– 4: admin-local scope
– 5: site-local scope
– 8: organization-local scope
– E: global scope
– F: reserved
– Other: unassigned
Table 1-3 shows the scopes and meanings of fixed IPv6 multicast addresses.
Table 1-3 Description of IPv6 Multicast Addresses
Scope Description
FF0x::/32 Indicates the well-known multicast addresses defined by

the IANA. For details, see Table 1-4.
FF1x::/32 (x cannot be 1 or 2) Indicates ASM addresses. The addresses are valid in the
FF2x::/32 (x cannot be 1 or 2) entire network.
FF3x::/32 (x cannot be 1 or 2) Indicates SSM addresses. This is the default SSM group
address scope, and is valid in the entire network.

Table 1-4 Description of commonly-used IPv6 multicast Addresses

Scope IPv6 Multicast Description
Address
Node/interface-local FF01:0:0:0:0:0:0:1 Indicates all node (interface) addresses.

scope
FF01:0:0:0:0:0:0:2 Indicates all router addresses.
Link-local scope FF02:0:0:0:0:0:0:1 Indicates all node addresses.
FF02:0:0:0:0:0:0:2 Indicates all router addresses.
FF02:0:0:0:0:0:0:3 Indicates the undefined address.
FF02:0:0:0:0:0:0:4 Indicates the Distance Vector Multicast

Routing Protocol (DVMRP) routers.
FF02:0:0:0:0:0:0:5 Indicates OSPF IGP routers.
FF02:0:0:0:0:0:0:6 Indicates OSPF IGP designated routers.
FF02:0:0:0:0:0:0:7 Indicates ST routers.
FF02:0:0:0:0:0:0:8 Indicates ST hosts.
FF02:0:0:0:0:0:0:9 Indicates RIP routers.
FF02:0:0:0:0:0:0:A Indicates EIGRP routers.
FF02:0:0:0:0:0:0:B Indicates mobile agents.
FF02:0:0:0:0:0:0:D Indicates all PIM routers.
FF02:0:0:0:0:0:0:E Indicates RSVP encapsulation.
FF02:0:0:0:0:0:1:1 Indicates the link name.
FF02:0:0:0:0:0:1:2 Indicates all DHCP agents.
FF02:0:0:0:0:1:FFXX:X Indicates the solicited node address.

XXX XX:XXXX indicates the last 24 bits of
the IPv6 address of a node.
Site-local scope FF05:0:0:0:0:0:0:2 Indicates all router addresses.
FF05:0:0:0:0:0:1:3 Indicates all DHCP severs.
FF05:0:0:0:0:0:1:4 Indicates all DHCP relays.
FF05:0:0:0:0:0:1:1000 to Indicates the service location.

FF05:0:0:0:0:0:1:13FF

1.4.2 IPv6 Multicast Protocols

To implement a complete set of IPv6 multicast services, various multicast protocols deployed
in a network need to cooperate with each other, as shown in Figure 1-3.
Figure 1-3 Location of each IPv6 multicast protocol
MLD Receiver
IPv6 Network UserA
PIM
Source
Receiver
Multicast UserB
PIM
Server
PIM
MLD Receiver
UserC
UserD
Table 1-5 IPv6 multicast protocols

Location Objectives Multicast Protocol
Between hosts Connecting hosts to a multicast network: Multicast Listener Discovery

and multicast l Implement the dynamic join and (MLD)
switches leaving of members at the host side.
l Manage and maintain the member
relationship at the switch side and
exchange information with the upper-
layer multicast routing protocols.
Between Multicast routing and forwarding: PIM-IPv6, including the PIM-

multicast l Create multicast routes on demand. DM and PIM-SM modes
switches
l Dynamically respond to the changes
of the network topology and maintain
the multicast routing table.
l Forward packets according to the
routing table.

1.4.3 Typical Configuration Solution
CAUTION
Customize configuration solutions according to the actual network conditions and service
requirements. The configuration solution in this section functions only as a reference.
The network environments are classified into two types, which are suitable for different
configuration solutions. For details, refer to the Quidway S9300 Terabit Routing Switch
Configuration Guide - Multicast.
NOTE
Ensure that IPv6 unicast routes work normally in the network before configuring IP multicast.
Small-Scale Network
A small-scale network, such as a test network, is suitable to implement multicast data
transmission in a Local Area Network (LAN), and does not interconnect with the Internet.
1. Enable multicast on all switches in the network.

2. Enable PIM-DM (IPv6) on all switch interfaces.
3. Enable MLD on switch interfaces connected to hosts.
Large-Scale Network
A large-scale network is suitable to transmit multicast services on an ISP network, and
interconnects with the Internet.
1. Enable multicast on all switches in the network.

2. Enable PIM-SM (IPv6) on all switch interfaces.
3. Enable MLD on switch interfaces connected to hosts.
4. Configure an RP. You can configure an embedded RP, a static RP, or a BSR-RP.
1.4.4 Controlling Multicast Forwarding

IP multicast guides the forwarding of multicast packets by using the multicast routing table and
forwarding table. You can adjust the transmission path of multicast data by configuring the RPF
routing policy, and limit multicast forwarding by configuring the forwarding policy and the
capacity of the forwarding table.
For details, refer to the chapter 14 IPv6 Multicast Routing Management in the Quidway
S9300 Terabit Routing Switch Configuration Guide - Multicast.

Configuration Guide - Multicast 2 IGMP Snooping Configuration
2 IGMP Snooping Configuration
About This Chapter
This chapter describes the procedure for configuring IGMP snooping and maintenance
commands, and provides configuration examples.
2.1 IGMP Snooping Overview

This section describes the functions and advantages of the IGMP snooping protocol.
2.2 IGMP Snooping Supported by the S9300
This section describes IGMP snooping features supported by the S9300.
2.3 Configuring IGMP Snooping
This section describes how to configure IGMP snooping in a VLAN.
2.4 Configuring Static Layer 2 Multicast
This section describes how to configure static multicast entries in a VLAN.
2.5 Configuring a Static Multicast MAC Address
This section describes how to configure a static multicast MAC address.
2.6 Configuring Layer 2 Multicast CAC
This section describes how to configure the Layer 2 multicast CAC function.
2.7 Configuring Layer 2 Multicast SSM Mapping
This section describes how to configure the Layer 2 multicast SSM mapping function.
2.8 Maintaining Layer 2 Multicast
Maintaining Layer 2 multicast involves resetting Layer 2 Multicast statistics, and debugging
IGMP Snooping.
2.9 Configuration examples
This section provides several configuration examples of Layer 2 multicast.

2.1 IGMP Snooping Overview

This section describes the functions and advantages of the IGMP snooping protocol.
Internet Group Management Protocol Snooping (IGMP snooping) is a Layer 2 multicast

protocol. The IGMP snooping protocol maintains information about the outgoing interfaces of
multicast packets by listening to multicast protocol packets exchanged between the router and
hosts. In this way, the IGMP snooping protocol manages and controls the forwarding of multicast
packets.
The IGMP snooping protocol forwards multicast information only to the specified receivers
through Layer 2 multicast. It has the following advantages:
l Reducing broadcast packets on Layer 2 networks, saving network bandwidth
l Enhancing the security of multicast information
l Performing accounting for each host independently
2.2 IGMP Snooping Supported by the S9300

This section describes IGMP snooping features supported by the S9300.
IGMP Snooping
The S9300 supports VLAN-based IGMP snooping.
IGMP snooping implements Layer 2 multicast and controls multicast data forwarding by
listening to multicast protocol packets sent between an upstream router and a downstream host
and maintaining downstream interface information.
You can configure user hosts to join a multicast group statically so that user hosts can steadily
receive multicast data packets.
You can also enable the S9300 to actively send IGMP Query messages so that the S9300 can
rapidly sense a Layer 2 network topology change and forward multicast data based on the new
topology, preventing multicast services from being interrupted.
Prompt Leave
When an interface of the S9300 receives an IGMP Leave message to leave a specified multicast
group, the S9300 deletes the interface from the downstream interface list of this multicast group
immediately. This is called prompt leave of a multicast group member. This feature is used in
the multicast IPTV scenario where one interface of the S9300 is commonly connected to only
one user host. Therefore, the prompt leave function shortens the speed at which the user switches
channels.
IGMP snooping prompt leave has the following advantages:

l Reducing response delay
l Saving the network bandwidth that is used by various types of messages

IGMP Snooping Querier

On a multicast network running IGMP, there should be a Layer 3 multicast device functioning
as an IGMP querier to send IGMP Query messages and create and maintain multicast forwarding
entries for normal multicast data forwarding.
If a multicast network does not have Layer 3 devices and Layer 2 devices do not support IGMP,
no IGMP querier can be configured. To solve such a problem, configure an IGMP snooping
querier on the Layer 2 device so that the Layer 2 device can create and maintain multicast
forwarding entries at the data link layer, implementing multicast data forwarding.
IGMP Snooping Proxy

Configuring IGMP snooping proxy on an edge device can reduce the number of IGMP Report
and Leave messages received by an upstream Layer 3 device and improve performance of the
upstream Layer 3 device. The device configured with IGMP snooping proxy functions as a host
for its upstream device and a querier for its downstream host.
IGMP Snooping Policies

Different IGMP snooping policies can be configured based on different requirements:
l To limit the number of multicast programs available to users and multicast data traffic on
an interface, set the maximum number of multicast groups that the interface can join.
l To allow users to order specified multicast programs, configure a multicast group policy.
l To reduce the number of packets transmitted over the network, configure IGMP message
suppression so that only the first IGMP Report or Leave message can be forwarded.
l If multicast services are stable, for example, the static Layer 2 multicast service, unknown
multicast data packets do not need to be processed. You can enable the discarding of
multicast data packets in such a case.
IGMP Snooping SSM Mapping

In the SSM model, if IGMPv3 is run on a receiver host, you can specify the multicast source for
IGMPv3 multicast data packets; if only IGMPv1 or IGMPv2 can be run on the receiver host,
you cannot specify the multicast source for IGMPv1 or IGMPv2 multicast data packets. IGMP
snooping SSM mapping is a solution. It generates a mapping between a multicast group and a
multicast source. (*, G) information in IGMPv1 or IGMPv2 multicast data packets is then
mapped to (S, G) information, providing SSM services for the hosts running IGMPv1 or
IGMPv2.
Static Multicast MAC Address

In Layer 2 multicast, you can dynamically create multicast MAC address entries using Layer 2
multicast protocols such as IGMP snooping or manually configure multicast MAC address
entries. After a multicast MAC address is configured on an interface, the MAC address is bound
to the interface and multicast packets destined for this MAC address are forwarded only by this
interface.
Layer 2 Multicast CAC

CAC is short for Call Admission Control. The Layer 2 multicast CAC is a part of the IPTV
multicast solution. This function limits the number of IPTV programs in Layer 2 multicast,
ensuring the service quality for most users. This function has the following advantages:

l Controlling multicast service accurately

l Ensuring the service quality for most VoD users
l Reducing the impact of multicast attack
2.3 Configuring IGMP Snooping

This section describes how to configure IGMP snooping in a VLAN.
2.3.1 Establishing the Configuration Task
Applicable Environment
VLAN-based IGMP snooping runs on the S9300 between an upstream router and hosts. The
S9300 monitors the multicast protocol packets exchanged between the router and hosts to
maintain the forwarding entries for the multicast packets. In this manner, the S9300 manages
and controls forwarding of multicast data packets to implement Layer 2 multicast.
Pre-configuration Tasks
Before configuring IGMP snooping in a VLAN, complete the following tasks:
l Connecting interfaces and configuring the physical parameters of each interface to make
the physical layer in Up state
l Creating a VLAN
l Adding interfaces to the VLAN
Data Preparation
To configure IGMP snooping in a VLAN, you need the following data.
No. Data
1 ID of the VLAN
2 (Optional) Version of IGMP messages
3 Types and numbers of interfaces
4 (Optional) Parameters of a querier: interval

for sending IGMP General Query messages,
robustness variable, maximum response time,
and interval for sending Last Member Query
messages
5 (Optional) ACL rules applied to a multicast

policy
6 (Optional) Suppression duration of IGMP

messages
7 (Optional) Aging time of the router interface

No. Data
8 (Optional) Source IP address of IGMP Query

messages
2.3.2 Enabling IGMP Snooping
Context
By default, IGMP snooping is disabled on the S9300. You need to enable IGMP snooping on
the S9300 globally.
Procedure
Step 1 Run:
system-view
The system view is displayed.

Step 2 (Optional) Run:
assign multicast-resource-mode optimize
The multicast forwarding table is optimized.

If a multicast forwarding table needs to contain more than 4096 entries, run this command to
optimize the multicast forwarding table before enabling IGMP snooping.
Step 3 Run:
igmp-snooping enable
IGMP snooping is enabled globally.

Step 4 Run:
vlan vlan-id
The VLAN view is displayed.

Step 5 Run:
IGMP snooping is enabled in the VLAN.

NOTE
To enable the IGMP Snooping function of multi-VLANs, run the igmp-snooping enable [ vlan vlan-id1
[ to vlan-id2 ] & <1-10> ] command in the system-view.
----End
2.3.3 (Optional) Setting the IGMP Version
Context
According to the version of IGMP applied on a network, you can set the version of IGMP
messages that the S9300 with the IGMP snooping function can process.

Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
igmp-snooping version { 1 | 2 |3 }
The version of IGMP messages that the S9300 can process is set.
By default, the S9300 can process messages of IGMPv1 and IGMPv2 but cannot process
messages of IGMPv3.
NOTE
When the forwarding in a VLAN is based on the MAC address, the IGMP message version cannot be set
to IGMPv3.
----End
2.3.4 (Optional) Setting the Forwarding Mode of Multicast Data in

a VLAN
Context
You can set the forwarding mode of multicast data so that the multicast flows can be forwarded
based on IP addresses or MAC addresses. When multicast IP addresses are mapped to MAC
addresses, up to 32 IP addresses can be mapped to one MAC address. Therefore, it is
recommended that multicast data be forwarded based on IP addresses; otherwise, unregistered
users may receive the multicast data.
CAUTION
Before setting the forwarding mode of multicast data in a VLAN, disable IGMP snooping in the
VLAN. After setting the forwarding mode, enable IGMP snooping in the VLAN for the
configuration to take effect.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
l2-multicast forwarding-mode { ip | mac }
The multicast flows in the VLAN are forwarded based on IP addresses or MAC addresses.
By default, multicast flows are forwarded based on IP addresses.
----End
2.3.5 (Optional) Configuring a Static Router Interface
Context
On a network whose topology seldom changes, if a host needs to receive certain multicast packets
for a long time, you can configure the interface on the S9300 as a static router interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface interface-type interface-number
The interface view is displayed.
The interface can be an Ethernet interface, a GE interface, an XGE interface, or an Eth-Trunk

interface. It is the interface that connects the S9300 to the upstream router.
Step 3 Run:
igmp-snooping static-router-port vlan { vlan-id [ to vlan-id ] } &<1-10>
The interface is configured as a static router interface.
----End
2.3.6 (Optional) Disabling Dynamic Learning on Interfaces
Context
To control the multicast packets received by hosts, you can disable dynamic learning on
interfaces. After the dynamic learning function is disabled on interfaces, you can only configure
the static router interface and forwarding entries manually.
l After dynamic learning of router interfaces is disabled in a VLAN, interfaces in the VLAN
do not listen on IGMP Query messages. In this case, you need to configure a static router
interface manually.
l After dynamic learning is disabled on multicast member interfaces, you can only add
interfaces to a multicast group manually.

Procedure
l Disabling dynamic learning of router interfaces in a VLAN
1. Run:
system-view

2. Run:
vlan vlan-id

3. Run:
undo igmp-snooping router-learning
Dynamic learning of router interfaces is disabled in the VLAN.

By default, a router interface can be dynamically learned.
l Disabling an interface from learning forwarding entries dynamically
1. Run:
system-view

2. Run:

The interface can be an Ethernet interface, a GE interface, an XGE interface, or an
Eth-Trunk interface.
3. Run:
undo igmp-snooping learning vlan { vlan-id1 [ to vlan-id2 ] } &<1–10>
The interface is disabled from dynamically learning forwarding entries.

By default, an interface is enabled to dynamically learn forwarding entries.
----End
2.3.7 (Optional) Configuring IGMP Snooping Querier
Context
If IGMP messages sent from the upstream router cannot reach the S9300 for certain reasons, for
example, IGMP is not enabled or if the multicast forwarding entries on the upstream router are
statically configured and do not need to be dynamically learned, you can configure the IGMP
snooping querier on the S9300. The IGMP snooping querier then sends IGMP Query messages.
You can adjust parameters of the IGMP snooping querier as required.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
igmp-snooping querier enable
The IGMP snooping querier is enabled for the VLAN.

By default, an IGMP snooping querier is disabled.
igmp-snooping query-interval query-interval
The interval at which the querier sends IGMP General Query messages is set.
By default, the interval for sending IGMP General Query messages is 60 seconds.
igmp-snooping robust-count robust-count
The robustness variable of the querier is set.

By default, the robustness variable is 2.
igmp-snooping lastmember-queryinterval lastmember-queryinterval
The interval at which the querier sends Last Member Query messages is set.
By default, the interval for sending Last Member Query messages is 1 second.
----End
2.3.8 (Optional) Configuring Multicast Policies
Context
A multicast group policy in a VLAN is used to add the hosts in the VLAN to the specified
multicast groups and limit the number of multicast groups that a host can join.
NOTE
When you create an ACL for a multicast group policy of a VLAN, the configuration takes effect only if
you select deny in the rule command. That is, a multicast group policy can only prohibit hosts in a VLAN
from accessing all or specified multicast groups.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
igmp-snooping group-policy acl-number [ version number ]
A multicast group policy is configured for the VLAN. Interfaces in the VLAN can dynamically
join only the multicast group that matches the specified ACL rules.
By default, no multicast group policy is available in a VLAN. That is, hosts in a VLAN can join
any multicast group. If the IGMP version is not specified for a multicast policy, the S9300 applies
the policy to all IGMP messages regardless of their versions.
NOTE
If an advanced ACL is referenced by the group-policy, the ACL applies to the multicast group regardless
of the protocol type specified in the ACL.
----End
2.3.9 (Optional) Configuring Prompt Leave for Interfaces
Prerequisite
A basic ACL is configured to specify the IP multicast groups that hosts can leave.
For the configuration of the ACL, see ACL Configuration in the Quidway S9300 Terabit Routing
Switch Configuration Guide - Security.
Context
When an interface on the S9300 receives an IGMP Leave message from a host, the S9300 deletes
the forwarding entry that corresponds to the interface from the multicast forwarding table
immediately without waiting for the aging of the forwarding entry. This is called prompt leave.
When each interface in a VLAN is connected to only one host, you can enable prompt leave for
interfaces in the VLAN.
NOTE
Prompt leave takes effect for interfaces in a VLAN only when the S9300 can process IGMPv2 or IGMPv3
messages.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
igmp-snooping prompt-leave [ group-policy acl-number ]
Prompt leave is enabled for interfaces in the VLAN.

If group-policy acl-number is not specified, the S9300 immediately deletes the forwarding entry
corresponding to a member interface after receiving the Leave message from the interface.

By default, prompt leave is disabled for interfaces.
NOTE
On the S9300, the permit rule is applicable to all multicast groups by default. To configure prompt leave
for a specified multicast group, you need to use the rule deny source any command.
----End
2.3.10 (Optional) Configuring the S9300 to Respond to Changes of

a Layer 2 Network Topology
Context
This task is performed to enable the S9300 to detect changes of a Layer 2 network topology and
forward multicast packets correctly based on the new topology.
Do as follows on the S9300 that receives multicast packets from a router and forwards the
multicast packets to hosts.
Procedure
Step 1 Run:
system-view
Step 2 Run:
igmp-snooping send-query enable
The S9300 enabled with IGMP snooping is configured to respond to changes of a Layer 2
network topology.
NOTE
The function of responding to changes of Layer 2 network topology is usually used on a ring network.
When the topology of the ring network changes, theS9300 sends an IGMP Query message with the source
IP address being 192.168.0.1. The source IP address can be changed by the igmp-snooping send-query
source-address source-address command.
----End
2.3.11 (Optional) Modifying Parameters of IGMP Snooping in a

VLAN
Context
You can modify parameters of IGMP snooping to optimize the multicast performance on the
S9300 according to the actual situation of the network. The following parameters can be
modified:
l Suppression duration of IGMP messages

Within the suppression duration, the S9300 sends only one copy of the same IGMP
messages continuously sent by hosts to the upstream router. This reduces the number of
redundant messages.
l Aging time of a router interface
When a short-run congestion occurs on the network, the transmission of Query messages
from the IGMP querier to the S9300 takes a longer time. If the router interface ages in this
period, the S9300 does not send Report or Leave messages to the router interface. In this
case, forwarding of multicast data may be interrupted. As a result, you should set a longer
aging time for router interfaces on an unstable network.
l Maximum response time for IGMP Query messages
When hosts are required to respond to IGMP Query messages quickly, you can set a shorter
maximum response time. To avoid congestion caused by a large number of Response
messages sent by hosts, you can set a longer maximum response time.
l Router Alert option
The S9300 determines whether to process IGMP messages by checking the Router Alert
option in the messages. You can determine whether IGMP messages contains the Router
Alert option.
l Source IP address of IGMP Query messages sent by the S9300
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
igmp-snooping suppress-time suppress-time
The suppression duration of IGMP messages is set.

By default, the suppression duration of IGMP messages is 10 seconds.
NOTE
For IGMP Report and Leave messages, it is recommended that you set the suppression duration the same
as the maximum response time for these messages in a VLAN.
Step 4 Run:
igmp-snooping router-aging-time router-aging-time
The aging time of the router interface is set.

By default, the S9300 sets the aging time of the router interface as follows:
l If the router interface receives an IGMP Query message, the S9300 sets the aging time of
the interface to 180 seconds.
l If the router interface receives a PIM Hello message and the holdtime value of the Hello
message is larger than the remaining aging time of the interface, the S9300 sets the aging
time of the interface to the holdtime value contained in the PIM Hello message. If the holdtime

value is smaller than the remaining aging time of the router interface, the S9300 does not
change the aging time of the interface.
Step 5 Run:
igmp-snooping max-response-time max-response-time
The maximum response time for IGMP messages is set.

By default, the maximum response time for IGMP messages is 10 seconds.
NOTE
The maximum response time must be shorter than the interval for sending IGMP General Query messages.
Step 6 Run:
igmp-snooping require-router-alert
The S9300 is configured to process only the IGMP messages that contain the Router Alert option
in the IP header.
By default, the S9300 can process the IGMP messages that do not contain the Router Alert option
in the IP header from a VLAN.
Step 7 Run:
igmp-snooping send-router-alert
The S9300 is configured to send the IGMP messages that contain the Router Alert option in the
IP header.
By default, the S9300 sends the IGMP messages that contain the Router Alert option in the IP
header.
Step 8 Run:
quit

Step 9 Run:
igmp-snooping send-query source-address ip-address
The source address of the IGMP General Query message is configured.

By default, the source address of the IGMP General Query message is 192.168.0.1. When
192.168.0.1 is used by other devices on the network, you can run the igmp-snooping send-
query source-address command to change the source IP address of the IGMP General Query
message.
----End
2.3.12 (Optional) Configuring the IGMP Snooping Proxy for the

VLAN
Context
After the IGMP proxy is configured on the S9300, the S9300 replaces the upstream router to
send IGMP Query messages to the downstream devices, and receives the IGMP Report and
IGMP Leave messages from the downstream devices. In this way, bandwidth consumption
between the upstream router and the S9300 is reduced and the workload on the upstream router
is also reduced.

Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
igmp-snooping proxy
The IGMP snooping proxy is configured.
NOTE
After IGMP snooping proxy is enabled, the switch broadcasts IGMP Query messages to all interfaces in a
VLAN periodically, including the routing interfaces in the VLAN. This may result in the reelection of
IGMP querier. If the multicast network already has a querier, you are advised to use the igmp-snooping
proxy-uplink-port command to configure an interface as an IGMP snooping proxy uplink interface. No
IGMP Query message can be sent to this interface.
IGMP snooping proxy and IGMP snooping querier cannot be configured in the same VLAN.
----End
2.3.13 (Optional) Filtering Layer 2 Multicast Data on an Interface
Context
To reject certain types of multicast data, a network administrator can filter UDP packets from a
certain VLAN on an interface of the S9300.
Procedure
Step 1 Run:
system-view

Step 2 Run:

interface.
Step 3 Run:
multicast-source-deny vlan { vlan-id1 [ to vlan-id2 ] } & <1-10>
The Layer 2 multicast data from a certain VLAN on the interface is rejected.
----End
2.3.14 Checking the Configuration

Prerequisite
The configuration of IGMP snooping in a VLAN is complete.
Procedure
l Run the display igmp-snooping configuration command to check the configuration of
IGMP snooping.
l Run the display igmp-snooping [ vlan vlan-id ] command to check the configuration of
IGMP snooping in a VLAN.
l Run the display igmp-snooping statistics vlan [ vlan-id ] command to check the statistics
of IGMP snooping on a VLAN.
l Run the display igmp-snooping port-info [ vlan vlan-id [ group-address group-
address ] ] [ verbose ] command to check the information about member interfaces of a
multicast group.
l Run the display igmp-snooping router-port vlan vlan-id command to check the
information about router interfaces.
l Run the display igmp-snooping querier vlan [ vlan-id ] command to check the enabling
information about the IGMP snooping querier.
l Run the display l2-multicast forwarding-table vlan vlan-id [ source-address source-
address group-address | group-address ] command to check the multicast forwarding
table of a VLAN.
----End
Example
NOTE
If IGMP snooping is disabled in a VLAN, you can still configure IGMP snooping functions, but the
configuration does not take effect. In this case, no information is displayed after you run the display igmp-
snooping command.
If the configurations succeed, you can obtain the following information after running the display
igmp-snooping [ vlan vlan-id ] command:
l IGMP snooping is enabled in the VLAN.
l The IGMP version is set correctly.
l A multicast group policy is correctly set for the VLAN.
l Prompt leave is enabled for interfaces in the VLAN.
l Aging time of the router interface, interval for sending Last Member Query messages,
interval for sending IGMP General Query messages, maximum response time, suppression
duration of IGMP messages, and IGMP robustness variable are correctly set.
l The Router Alert option is set correctly.
The following is an example.
<Quidway> display igmp-snooping vlan 3
IGMP Snooping Information for VLAN 3
IGMP Snooping is Enabled
IGMP Version is Set to default 2
IGMP Query Interval is Set to default 125
IGMP Max Response Interval is Set to default 10
IGMP Robustness is Set to default 2
IGMP Last Member Query Interval is Set to default 1
IGMP Router Port Aging Interval is Set to 180s or holdtime in hello
IGMP Filter Group-Policy is Set to default : Permit All

IGMP Prompt Leave Disable

IGMP Router Alert is Not Required
IGMP Send Router Alert Enable
IGMP Proxy Enable
IGMP Report Suppress Disable
IGMP Suppress Time is set to default 10 seconds
IGMP Querier Disable
IGMP Router Port Learning Enable
IGMP SSM-Mapping Disable
When the dynamic interface learning is disabled, if you run the display igmp-snooping port-
info [ vlan vlan-id ] [ group-address group-address ] [ verbose ] command, only the static
entries are displayed.
<Quidway> display igmp-snooping port-info
-----------------------------------------------------------------------
(Source, Group) Port Flag
Flag: S:Static D:Dynamic M: Ssm-mapping
-----------------------------------------------------------------------
VLAN 101, 1 Entry(s)
(*, 225.0.0.1) GE1/0/1 -D-
1 port(s)
VLAN 102, 1 Entry(s)
(*, 225.0.0.1) GE1/0/2 -D-
1 port(s)
-----------------------------------------------------------------------
<Quidway> display igmp-snooping router-port vlan 3
Port Name UpTime Expires Flags
--------------------------------------------------------------
VLAN 3, 2 router-port(s)
GE2/0/1 1d:22h 00:01:20 DYNAMIC
GE2/0/3 2d:10h -- STATIC
Run the display igmp-snooping querier vlan [ vlan-id ] command. If the querier is displayed
as Enabled, it indicates that the querier is successfully enabled.
<Quidway> display igmp-snooping querier vlan
VLAN Querier-state
-----------------------------------------------
3 Enable
total entry 1
Run the display l2-multicast forwarding-table vlan 7 command, and you can view the
multicast forwarding table of VLAN 7.
<Quidway> display l2-multicast forwarding-table vlan 7
VLAN ID : 7, Forwarding Mode : IP
-----------------------------------------------------------------------
(Source, Group) Interface Out-Vlan
-----------------------------------------------------------------------
(1.1.1.1, 232.1.1.1) GigabitEthernet2/0/0 7
-----------------------------------------------------------------------
Total Group(s) : 1
2.4 Configuring Static Layer 2 Multicast

This section describes how to configure static multicast entries in a VLAN.

In a metro Ethernet, if a host connected to an interface of the S9300 needs to receive the multicast
flow of a certain multicast group for a long time, you can add the interface to the multicast group.
After static Layer 2 multicast is configured, hosts can receive the multicast flows of the registered
multicast group in a steady and timely manner for a long time. However, in this mode, all the
forwarding entries need to be manually configured. This makes the maintenance difficult, so
this mode is not applicable to a complicated network.
Before configuring static Layer 2 multicast in a VLAN, complete the following tasks:
l Connecting interfaces and configuring the physical parameters of each interface to make
the physical layer in Up state
l Enabling IGMP snooping globally
Data Preparation
To configure static Layer 2 multicast, you need the following data.
No. Data
1 Type and number of the interface that needs

to join a multicast group statically
2 ID of the VLAN that the interface belongs to
3 IP address of the multicast group
2.4.2 Creating a VLAN and Enabling IGMP Snooping
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
A VLAN is created and the VLAN view is displayed.
Step 3 Run:
The IGMP snooping is enabled in the VLAN.
----End

2.4.3 (Optional) Setting the Forwarding Mode of Multicast Data in

a VLAN
Context
You can set the forwarding mode of multicast data so that the multicast flows can be forwarded
based on IP addresses or MAC addresses. When multicast IP addresses are mapped to MAC
addresses, up to 32 IP addresses can be mapped to one MAC address. Therefore, it is
recommended that multicast data be forwarded based on IP addresses; otherwise, unregistered
users may receive the multicast data.
CAUTION
Before setting the forwarding mode of multicast data in a VLAN, disable IGMP snooping in the
VLAN. After setting the forwarding mode, enable IGMP snooping in the VLAN for the
configuration to take effect.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
l2-multicast forwarding-mode { ip | mac }
The multicast flows in the VLAN are forwarded based on IP addresses or MAC addresses.
By default, multicast flows are forwarded based on IP addresses.
----End
2.4.4 Adding an Interface to a VLAN
Procedure
Step 1 Run:
system-view

Step 2 Run:


interface.
Step 3 Run:
port hybrid tagged vlan { { vlan-id1 [ to vlan-id2 ] }&<1-10> | all }
The interface is added to VLANs.
NOTE
If multicast VLAN replication is not configured, the interface of the S9300 that connects to a router and
receives the multicast packets from the router and the interface that connects to users and sends multicast
packets to users must be added to the same VLAN.
----End
2.4.5 Adding an Interface to a Multicast Group Statically
Procedure
Step 1 Run:
system-view
Step 2 Run:

interface.
Step 3 Run:
l2-multicast static-group [ source-address source-ip-address ] group-address group-
ip-address vlan { vlan-id1 [ to vlan-id2 ] } &<1-10>
The interface is added to the multicast group statically. You can also run the l2-multicast static-
group [ source-address source-ip-address ] group-address group-ip-address1 to group-ip-
address2 vlan vlan-id command to join the interface to the group-address in batches.
After an interface is added to a multicast group statically, multicast protocol packets are not
forwarded to the router interface.
----End
Prerequisite
The configuration of static Layer 2 multicast for a VLAN is complete.

Procedure
l Run the display l2-multicast forwarding-table vlan vlan-id [ source-address source-
address group-address group-address ] command to check the multicast forwarding table
of a VLAN.
----End
Example
Run the display l2-multicast forwarding-table vlan 10 command, and you can view the
multicast forwarding table of VLAN 10.
<Quidway> display l2-multicast forwarding-table vlan 10
--------------------------------------------------------------------
--------------------------------------------------------------------
Router-port GigabitEthernet1/0/1 10
(*, 225.1.1.1) GigabitEthernet1/0/1 10
GigabitEthernet1/0/2 10
--------------------------------------------------------------------
Total Group(s) : 3
2.5 Configuring a Static Multicast MAC Address

This section describes how to configure a static multicast MAC address.
If a Layer 2 switch receives a multicast data packet whose destination MAC address is not a
multicast MAC address, the switch cannot find the matching entry in the MAC address table.
Therefore, the switch broadcasts the multicast packet in the VLAN. This wastes bandwidth and
threatens network security.
To save bandwidth and ensure network security, configure a static multicast MAC address on
an interface so that multicast packets destined for the multicast MAC address are forwarded only
by this interface.
Before configuring a static multicast MAC address, complete the following task:
l Creating a VLAN and adding the interface that needs to be configured with a static multicast
MAC address to the VLAN
Data Preparation
To configure a static multicast MAC address, you need the following data.

No. Data
1 Number of the interface to be configured with

a static multicast MAC address
2 ID of the VLAN that the interface belongs to
2.5.2 Configuring a Static Multicast MAC Address
Procedure
Step 1 Run:
system-view
Step 2 Configure a static multicast MAC address:

l Configure a static multicast MAC address on an interface:
1. Run:

The interface type can be Ethernet, GE, XGE, or Eth-Trunk.
2. Run:
mac-address multicast mac-address vlan vlan-id
A static multicast MAC address is configured on the interface.

l Configure a static multicast MAC address on multiple interfaces:
Run:
mac-address multicast mac-address interface { interface-type interface-number1
[ to interface-type interface-number2 ] } &<1–10> vlan vlan-id
The static multicast MAC address is configured on multiple interfaces.

The interface numbers must be consecutive; the specified interfaces must be on the same
board; interface-number2 must be greater than interface-number1.
After a static multicast MAC address is configured on interfaces, multicast packets destined for
the multicast MAC address are forwarded only to the interfaces.
Note the following points when configuring a static multicast MAC address:
l The specified VLAN exists and the interfaces have been added to the VLAN.
l The value of mac-address must be a multicast MAC address, which starts with 01.
l The MAC address cannot be in the range from 0100-5E00-0000 to 0100-5E00-7FFF (used
for IPv4 multicast) or 3333-xxxx-xxxx (used for IPv6 multicast).
l The VLAN cannot be a super-VLAN, a leased line VLAN, or the control VLAN of a Smart
Ethernet Protocol (SEP) segment or Rapid Ring Protection Protocol (RRPP) ring.
----End

Prerequisite
The configurations of a static multicast MAC address are complete.
Procedure
l Run the display mac-address multicast [ mac-address ] [ vlan vlan-id ] command to check
the configured static multicast MAC addresses.
l Run the display mac-address multicast [ vlan vlan-id ] total-number command to check
the number of configured static multicast MAC addresses.
----End
Example
# View static multicast MAC address entries in VLAN 10.
<Quidway> display mac-address multicast vlan 10
--------------------------------------------------------------------
MAC Address VLANID Out-Interface
--------------------------------------------------------------------
0111-1111-2222 10 GigabitEthernet1/0/1
GigabitEthernet1/0/2
2 port(s)
--------------------------------------------------------------------
Total Group(s) : 1
# View the number of static multicast MAC address entries in VLAN 10.
<Quidway> display mac-address multicast vlan 10 total-number
Total number of mac-address : 3
2.6 Configuring Layer 2 Multicast CAC

This section describes how to configure the Layer 2 multicast CAC function.
As shown in Figure 2-1, the UPE is connected to downlink devices through a Layer 2 network.
IGMP snooping is deployed on the UPE to implement multicast CAC on the VLAN, allowing
the UPE to control the number of IPTV channels requested by the downstream DSLAM or
switch.

Figure 2-1 Networking diagram of multicast CAC
BTV
NPE
IP/MPLS
Core
Switch
UPE DSLAM
CE
NOTE
You can choose to configure multicast CAC for a VLAN, a Layer 2 interface, or an interface in a VLAN,
or you can configure multicast CAC for all of them.
The UPE can work in either of the following scenarios to provide multicast services based on
VLANs:
l Static multicast groups are configured on the NPE and the UPE is configured as the querier.
In this scenario, the UPE does not process Query messages from the NPE. Instead, the UPE
only learns the Report messages sent from the user side to generate corresponding multicast
forwarding entries.
The UPE sends General Query messages periodically. If the UPE does not receive Report
messages from the user side, the corresponding entries on the UPE ages. When receiving
Leave messages, the UPE sends Group-Specific Query messages. You can also configure
static multicast groups on the UPE.
l IGMP snooping is enabled on the UPE. When receiving Query messages from the NPE,
the UPE forwards the Query messages to all members on the VLAN. After receiving Report
messages from the user side, the UPE creates corresponding multicast forwarding entries.
If the later received Query message is from the same group and the corresponding multicast
forwarding entry does not reach the aging time, the UPE directly sends a Report message
to the NPE.

NOTE
This section describes only the scenario where IGMP snooping is deployed.
Before configuring multicast CAC for a VLAN, a Layer 2 interface, or an interface in a VLAN,
complete the following tasks:
l Connecting interfaces between devices correctly

l Configuring interfaces on the switches to ensure that the link layer protocol between the
switches is Up
Data Preparation
To configuring Layer 2 multicast CAC for a VLAN, a Layer 2 interface, or an interface in a
VLAN, you need the following data.
No. Data
1 Channel name
2 Number of multicast group members
3 Number of multicast group members in a channel
4 ID of the VLAN or the type and number of the interface where multicast CAC
needs to be configured
2.6.2 Limiting the Number of Multicast Groups of a VLAN, a Layer

2 Interface, or an Interface in a VLAN
Procedure
Step 1 Run:
system-view
Step 2 Run:
l2-multicast limit max-entry count [ except acl-number ]
Limitation on the number of global multicast groups is configured.
Step 3 Run:
l2-multicast limit max-entry count vlan { { vlan-id [ to vlan-id ] } &<1-10> }
[ except acl-number ]
Limitation on the number of multicast groups in a VLAN is configured.
Step 4 Run:

The Ethernet, GigabitEthernet, or Eth-Trunk interface view is displayed.
Step 5 Run:
l2-multicast limit max-entry count [ except acl-number ]
Limitation on the number of multicast groups on a Layer 2 interface is configured.
Step 6 Run:
l2-multicast limit max-entry count [ vlan { { vlan-id [ to vlan-id ] } &<1-10> } ]
[ except acl-number ]
Limitation on the number of multicast groups on an interface of a VLAN is configured.
NOTE
The interface-based Layer 2 multicast CAC is applicable to only the multicast VLAN, but not applicable
to user VLANs.
The except acl-number parameters exclude the multicast groups that are not limited. The parameters have
the same function in other configuration commands.
----End
2.6.3 Limiting the Number of Multicast Groups in a Channel for a

VLAN, an Interface, or an Interface in a VLAN
Procedure
Step 1 Run:
system-view
Step 2 Run:
l2-multicast limit channel channel-name { max-entry count } [ vlan { { vlan-id
[ to vlan-id ] } &<1-10> } ]
Limitation on the number of multicast groups in a channel is configured for the entire system or
a VLAN.
Step 3 Run:
The Ethernet, GigabitEthernet, or Eth-Trunk interface view is displayed.
Step 4 Run:
l2-multicast limit channel channel-name { max-entry count }
Limitation on the number of multicast groups in a channel is configured on the interface.
Step 5 Run:
l2-multicast limit channel channel-name { max-entry count } [ vlan { { vlan-id
[ to vlan-id ] } &<1-10> } ]
Limitation on the number of multicast groups in a channel is configured for the interface in a
specified VLAN.
----End

2.6.4 Configuring Channels on a VLAN
Context
Do as follows on the UPE.
Procedure
Step 1 Run:
system-view

Step 2 (Optional) Configure the global channels.
1. Run:
l2-multicast-channel
The global channel view is displayed.

2. Run:
channel channel-name [ type [ asm | ssm ] ]
A global channel is configured and the channel view is displayed.

3. Run:
group group-address { group-mask-length | group-mask }
The multicast group member in the global channel is configured.

Step 3 Run:
quit
Return to the system view.

Step 4 Run:
l2-multicast-channel vlan vlan-id
The VLAN channel view is displayed.

The VLAN specified in this command must be a VLAN that is not bound to a VSI and must not
be a user VLAN or a protection VLAN. Otherwise, the channel cannot be configured.
Step 5 Run:
channel channel-name
The channel name is created.

The name of a VLAN channel must be different from the name of a global channel.
Step 6 Run:
group group-address { group-mask-length | group-mask }
The multicast group member in the channel is configured.

The specified group address must be different from the group addresses specified for other
channels in this VLAN or the group address of the global channel.
Step 7 Run:
quit

Return to the system view.
----End
Prerequisite
The configurations of Layer 2 multicast CAC for a VLAN, a Layer 2 interface, or an interface
in a VLAN are complete.
Procedure
l Run the display l2-multicast limit configuration command to check the configuration of
Layer 2 multicast CAC.
l Run the display l2-multicast limit configuration vlan [ vlan-id ] command to check the
configuration of multicast CAC in a VLAN.
l Run the display l2-multicast limit vlan [ vlan-id] [ channel channel-name ] command to
check the multicast CAC configuration of a channel in the VLAN.
l Run the display l2-multicast limit interface interface-type interface-number command to
check the configuration of multicast CAC on an interface.
l Run the display l2-multicast limit channel channel-name command to check the multicast
CAC configuration in a channel.
l Run the display l2-multicast-channel channel channel-name command to check the
channel configuration.
----End
Example
Run the display l2-multicast limit configuration command, and you can check the
configuration of Layer 2 multicast CAC.
<Quidway> display l2-multicast limit configuration
L2-multicast limit information, The unit of bandwidth is kbits/sec
---------------------------------------------------------------------
ConfigEntries ConfigBandwidth
CurrentEntries CurrentBandwidth
---------------------------------------------------------------------
Global limit information:
---------------------------------------------------------------------
100 -------
---- -------
VLAN 20 limit information:
---------------------------------------------------------------------
50 -------
---- -------
VLAN 20 channel limit information:
---------------------------------------------------------------------
bjtv 15 -------
---- -------
interface GigabitEthernet1/0/1 VLAN 10 channel limit information:
---------------------------------------------------------------------
cctv 20 -
---- -------
Run the display l2-multicast-channel vlan 10 command, and you can check the channel
configuration of a VLAN.

<Quidway> display l2-multicast-channel vlan 10

Channel information on VLAN 10
ChannelName Group/Mask Source/Mask Bandwidth
-------------------------------------------------------------------------------
njtv 226.1.1.0/24 * 0
226.1.2.0/24 * 0
226.1.3.0/24 * 0
---------------------------------------------------------------------
njtv1 226.2.1.0/24 * 0
226.2.2.0/24 * 0
Run the display l2-multicast limit vlan 20 command, and you can check the configuration of
multicast CAC of a VLAN.
<Quidway> display l2-multicast limit vlan 20
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
50 ----
0 ----
---------------------------------------------------------------------
bjtv 15 ----
0 ----
Run the displayl2-multicast limit vlan 10 interface gigabitethernet 1/0/1 command, and you
can check the configuration of multicast CAC on an interface in a VLAN.
<Quidway> display l2-multicast limit vlan 10 interface gigabitethernet 1/0/1
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
cctv 20 ----
---- -------
2.7 Configuring Layer 2 Multicast SSM Mapping

This section describes how to configure the Layer 2 multicast SSM mapping function.
If the switch connected to user hosts is configured with IGMPv3, SSM mapping needs to be
configured on the switch to map the multicast group addresses not in the SSM group to the
specified source addresses.
When the switch running IGMPv3 receives an IGMPv2 packet whose address is in the SSM
group, the SSM mapping function can automatically map the address of the packet to the
specified source.

Before configuring SSM mapping, complete the following task:
l Enabling global IGMP snooping
Data Preparation
To configure SSM mapping, you need the following data.
No. Data
1 (Optional) ACL rule
2 (Optional) SSM policy
3 Source addresses mapped to the multicast group addresses
2.7.2 (Optional) Configuring an SSM Group Policy
Context
If a user joins an ASM multicast group, you need to configure an SSM group policy in the VLAN
to add the multicast group address to the range of SSM group addresses.
NOTE
When you create an ACL for an SSM policy, the configuration takes effect only if you select permit and
specify a multicast address in the rule command. The configuration does not take effect if deny is selected
or if the specified address is not a multicast address.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
igmp-snooping ssm-policy basic-acl-number
An SSM group policy is configured.

By default, the address of an SSM group ranges from 232.0.0.0 to 232.255.255.255. After you
configure an SSM policy, the multicast groups specified in the SSM policy are considered as
SSM groups.
----End
2.7.3 (Optional) Configuring Layer 2 Multicast SSM Mapping

Context
By configuring SSM mapping, you can set up one-to-one mappings between multicast groups
and multicast sources.
SSM mapping can be configured only when IGMP snooping is enabled globally and in the
corresponding VLAN and when the IGMP messages version is set to IGMPv3 in the VLAN.
If the multicast replication function is configured, you only need to configure SSM mapping in
the multicast VLAN.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp-snooping version 3
The version number of IGMP 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
SSM mapping is enabled in the VLAN.
By default, SSM mapping is disabled.
Step 5 Run:
igmp-snooping ssm-mapping ip-group-address { ip-group-mask | mask-length } ip-
source-address
The mapping between a multicast group address and a multicast source is configured.
The specified multicast group address must be in the range of multicast group addresses specified
by the SSM policy. For the configuration of the SSM policy, see 2.7.2 (Optional) Configuring
an SSM Group Policy.
----End
Prerequisite
The configurations of SSM mapping are complete.

Procedure
l Run the display igmp-snooping port-info command to view the IGMP snooping entries
on an interface.
----End
Example
Run the display igmp-snooping port-info command, and you can view the IGMP snooping
entries on the interface. For example:
<Quidway> display igmp-snooping port-info vlan 10
-----------------------------------------------------------------------
-----------------------------------------------------------------------
VLAN 10, 3 Entry(s)
(*, 225.1.1.1) GE1/0/2 --M
1 port(s)
(*, 225.1.1.2) GE1/0/2 --M
1 port(s)
(*, 225.1.1.3) GE1/0/2 --M
1 port(s)
-----------------------------------------------------------------------
2.8 Maintaining Layer 2 Multicast

Maintaining Layer 2 multicast involves resetting Layer 2 Multicast statistics, and debugging
IGMP Snooping.
2.8.1 Clearing Static Entries in a Multicast Forwarding Table
Context
CAUTION
Static entries in a forwarding table cannot be restored after you clear them and you have to
configure them again. Confirm the operation before you run the following command.
Procedure
Step 1 Run:
system-view
Step 2 Run:


interface.
Step 3 Run:
undo l2-multicast static-group [ source-address source-ip-address ] group-address
group-ip-address vlan { all | { vlan-id1 [ to vlan-id2 ] } & <1-10> }
The interface is removed from a multicast group.
Or run:
undo l2-multicast static-group [ source-address source-ip-address ] group-address
group-ip-address1 to group-ip-address2 vlan vlan-id
The interface is removed from multiple multicast groups in a batch.
----End
2.8.2 Clearing Multicast Forwarding Entries
Context
CAUTION
Running this command disables hosts in a VLAN from receiving certain multicast flows. The
hosts in the VLAN receive the multicast flows again only after the S9300 receives IGMP Report
messages from the hosts again and the forwarding entries are regenerated on the S9300.
Procedure
l Run the reset igmp-snooping group { all | vlan { vlan-id | all } } command in the user
view to clear the dynamic forwarding entries in the multicast forwarding table.
NOTE
This command cannot clear static forwarding entries and dynamic router port entries.
----End
2.8.3 Clearing the Statistics on IGMP Snooping
Context
CAUTION
The statistics on IGMP snooping cannot be restored after you clear them. So, confirm the action
before you use the command.

Procedure
l Run the reset igmp-snooping statistics { all | vlan { vlan-id | all } } command in the user
view to clear the statistics on IGMP snooping.
----End
2.8.4 Debugging IGMP Snooping
Context
CAUTION
Debugging affects the performance of the system. So, after debugging, run the undo debugging
igmp-snooping all command to disable it immediately.
Procedure
l Run the debugging igmp-snooping { all | aps | event | fwd | general | leave [ basic-acl-
number ] | mvlan | packet [ advance-acl-number ] | query [ advance-acl-number ] |
report [ advance-acl-number ] | syn | timer } command in the user view to enable
debugging of IGMP snooping.
----End
2.8.5 Debugging Layer 2 Multicast CAC
Context
CAUTION
all command to disable it immediately.
Procedure
l Run the debugging l2-multicast limit { all | check | configuration | event }command to
enable the debugging of multicast CAC.
----End
2.9 Configuration examples

This section provides several configuration examples of Layer 2 multicast.

2.9.1 Example for Configuring IGMP Snooping
Networking Requirements
As shown in Figure 2-2, GE 3/0/1 of the S9300 is connected to a router on the multicast source
side, and GE 1/0/1 is connected to hosts. You are required to configure IGMP snooping to ensure
that three hosts in VLAN 3 can receive multicast data from multicast groups in the range of
225.1.1.1 to 225.1.1.3 permanently.
Figure 2-2 Networking diagram for configuring VLAN-based IGMP snooping
DHCP server Multicast source
IP/MPLS core
GE3/0/1
Switch
GE1/0/1
VLAN3
Host3 Host4 Host5
Configuration Roadmap
The configuration roadmap is as follows:
1. Create a VLAN and add interfaces to the VLAN.

2. Enable IGMP snooping globally and in the VLAN.
3. Configure a static router interface.
4. Configure static multicast groups 225.1.1.1, 225.1.1.2, and 225.1.1.3.
Data Preparation
To complete the configuration, you need the following data:
l ID of the VLAN that GE 1/0/1 and GE 3/0/1 belong to: VLAN 3

l Static router interface: GE 3/0/1

l Addresses of static multicast groups: 225.1.1.1, 225.1.1.2, 225.1.1.3
Procedure
Step 1 Create a VLAN and add interfaces to the VLAN.
<Switch> system-view
[Switch] vlan 3
[Switch-vlan3] quit
[Switch] interface gigabitethernet 3/0/1
[Switch-GigabitEthernet3/0/1] port hybrid tagged vlan 3
[Switch-GigabitEthernet3/0/1] quit
[Switch-GigabitEthernet1/0/1] port hybrid tagged vlan 3
Step 2 Enable IGMP snooping.

# Enable IGMP snooping globally.
[Switch] igmp-snooping enable
# Enable IGMP snooping in VLAN 3.

[Switch] vlan 3
[Switch-vlan3] igmp-snooping enable
[Switch-vlan3] quit
Step 3 Configure GE 3/0/1 as the static router interface of VLAN 3.

[Switch-GigabitEthernet3/0/1] igmp-snooping static-router-port vlan 3
Step 4 Configure static multicast groups.

[Switch-GigabitEthernet1/0/1] l2-multicast static-group group-address 225.1.1.1
vlan 3
vlan 3
vlan 3
Step 5 Verify the configuration.

# Check all configurations of IGMP snooping.
<Switch> display igmp-snooping vlan configuration
IGMP Snooping Configuration for VLAN 3
According to the preceding information, the IGMP snooping of the VLAN is enabled.
# Check the configuration of the static router interface.
Run the display igmp-snooping router-port vlan 3 command on the S9300.
<Switch> display igmp-snooping router-port vlan 3
---------------------------------------------------------------------
VLAN 3, 1 router-port(s)
GigabitEthernet3/0/1 00:01:02 -- STATIC
According to the preceding information, GE 3/0/1 is configured as a static router interface.

# Verify the information about member interfaces of a static multicast group.

[Switch] display igmp-snooping port-info

-----------------------------------------------------------------------
-----------------------------------------------------------------------
VLAN 3, 3 Entry(s)
(*, 225.1.1.1) GE1/0/1 S--
1 port(s)
(*, 225.1.1.2) GE1/0/1 S--
1 port(s)
(*, 225.1.1.3) GE1/0/1 S--
1 port(s)
-----------------------------------------------------------------------
According to the preceding information, multicast groups 225.1.1.1 to 225.1.1.3 are configured
with static forwarding entries.
# View the multicast forwarding table.

[Switch] display l2-multicast forwarding-table vlan 3
--------------------------------------------------------------------
--------------------------------------------------------------------
Router-port GigabitEthernet3/0/1 3
--------------------------------------------------------------------
Total Group(s) : 3
The preceding information shows the VLAN ID and outgoing interface mapping the data from
multicast groups 225.1.1.1 to 225.1.1.3.
----End
Configuration Files
l Configuration file of the S9300
#
sysname Switch
#
vlan batch 3
#
#
vlan 3
#
interface GigabitEthernet1/0/1
port hybrid tagged vlan 3
l2-multicast static-group group-address 225.1.1.1 to 225.1.1.3 vlan 3
#
igmp-snooping static-router-port vlan 3
#
return
2.9.2 Example for Configuring Layer 2 Multicast CAC for a VLAN

As shown in the figure, Switch A and Switch B are connected through VLAN 20; Switch B and
Switch C are connected through the MPLS/VPLS network and Switch C is connected to the TV
server on the Internet.
The Layer 2 multicast CAC based on VLAN 20 is configured on GE1/0/0 of Switch B. The
multicast CAC limits the number of multicast groups in VLAN 20 to 50 and the number of
multicast group members in channel bjtv in VLAN 20 to 15.
An intranet is connected to GE1/0/1 of Switch B through VLAN 10. The VLAN-based multicast
CAC is configured on GE1/0/1 in VLAN 10 to limit the channel that users can join to cctv and
the number of members in the channel to 20.
Figure 2-3 Networking diagram of Layer 2 multicast CAC for a VLAN
SwitchB
GE1/0/1
VLAN20 GE1/0/0 MPLS/ Internet
VPLS
SwitchA GE1/0/1 SwitchC TV Server
VLAN10
1. Configure VLAN 20 on Switch A and Switch B.
2. Enable global IGMP snooping.
3. Configure Layer 2 multicast CAC in the system view and the VLAN view.
4. Configure multicast groups for the channel in VLAN 10 on Switch B.
5. Configure VLAN-based Layer 2 multicast CAC on an interface of Switch B in VLAN 10.
Data Preparation
1. VLAN ID between Switch A and Switch B
2. Limits of Layer 2 multicast CAC, including number of multicast groups and number of
channels
Procedure
Step 1 Configure VLAN 20 on Switch A and Switch B.
# Configure Switch A.

<SwitchA> system-view
[SwitchA] vlan 20
[SwitchA-vlan20] quit
[SwitchA] interface gigabitethernet 1/0/1
[SwitchA-GigabitEthernet1/0/1] port link-type access
[SwitchA-GigabitEthernet1/0/1] port default vlan 20
[SwitchA-GigabitEthernet1/0/1] quit
# Configure Switch B.
<SwitchB> system-view
[SwitchB] vlan 20
[SwitchB-vlan20] quit
[SwitchB] interface gigabitethernet 1/0/0
[SwitchB-GigabitEthernet1/0/0] port link-type access
[SwitchB-GigabitEthernet1/0/0] port default vlan 20
[SwitchB-GigabitEthernet1/0/0] quit
[SwitchB] interface gigabitethernet 1/0/1
[SwitchB-GigabitEthernet1/0/1] port link-type trunk
[SwitchB-GigabitEthernet1/0/1] port trunk allow-pass vlan 10
Step 2 Enable global IGMP snooping on Switch A and Switch B.

[SwitchA] igmp-snooping enable
[SwitchB] igmp-snooping enable
Step 3 Enable IGMP snooping in VLANs.

# Enable IGMP snooping for VLAN 10 and VLAN 20 on Switch B.
[SwitchB] vlan 20
[SwitchB-vlan20] igmp-snooping enable
[SwitchB-vlan20] quit
[SwitchB] vlan 10
[SwitchB-vlan10] igmp-snooping enable
# Enable IGMP snooping for VLAN 20 on Switch A.

[SwitchA] vlan 20
[SwitchA-vlan20] igmp-snooping enable
Step 4 Configure Layer 2 multicast CAC in the system view and configure the group limit to 100
globally. The multicast CAC limits the number of multicast groups in VLAN 20 to 50 and the
number of multicast group members in channel bjtv in VLAN 20 to 15
[SwitchB] l2-multicast limit max-entry 100
[SwitchB] l2-multicast limit max-entry 50 vlan 20
[SwitchB] l2-multicast limit channel bjtv max-entry 15 vlan 20
Step 5 Configure Layer 2 multicast CAC on GE1/0/1 of Switch B. The VLAN-based multicast CAC
is configured on GE1/0/1 in VLAN 10 to limit the channel that users can join to cctv and the
number of members in the channel to 20
[SwitchB]interface gigabitethernet 1/0/1
[SwitchB-GigabitEthernet1/0/1]l2-multicast limit channel cctv max-entry 20 vlan 10

Run the display l2-multicast limit configuration command to check the configurations of Layer
2 multicast CAC.
The following are the configurations of Switch B.
[SwitchB] display l2-multicast limit configuration
---------------------------------------------------------------------
---------------------------------------------------------------------
Global limit information:

---------------------------------------------------------------------
100 -
---- ----------
---------------------------------------------------------------------
50 -
---- ----------
---------------------------------------------------------------------
bjtv 15 -
---- ----------
---------------------------------------------------------------------
cctv 20 -
---- ----------
Run the display l2-multicast limit vlan 20 command to check the configurations of Layer 2
multicast CAC in VLAN 20.
[SwitchB] display l2-multicast limit vlan 20
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
50 -
0 -
---------------------------------------------------------------------
bjtv 15 -
0 -
Run the displayl2-multicast limit vlan 10 interface command to check the configurations of
multicast CAC of an interface in the VLAN.
[SwitchB] display l2-multicast limit vlan 10 interface gigabitethernet 1/0/1
L2-multicast limit information, The unit of bandwidth is Mbits/sec
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
cctv 20 -
20 -
----End
Configuration Files
l Configuration file of SwitchA
#
sysname SwitchA
#
vlan batch 20
#
#
vlan 20
#

port link-type trunk

port trunk allow-pass vlan 20
#
return
l Configuration file of Switch B

#
sysname SwitchB
#
vlan batch 10 20
#
l2-multicast limit max-entry 100
l2-multicast limit max-entry 50 vlan 20
l2-multicast limit channel bjtv max-entry 15 vlan 20
#
vlan 10
#
vlan 20
#
port link-type access
port default vlan 20
#
l2-multicast limit channel cctv max-entry 20 vlan 10
#
return
2.9.3 Example for Configuring IGMP Snooping SSM Mapping
On the network shown in Figure 2-4, IGMPv2 is run on Switch and Host 1 and Host 2, and
IGMPv3 is run on the last-hop router Router A on the multicast source side. Switch A is the
S9300 device. GE 1/0/0 on Switch A is connected to Router A and GE 1/0/1 on Switch A is
connected to a switch directly connected with users. GE 1/0/0 on Switch A is a static router
interface and GE 1/0/1 is statically added to multicast group 224.1.1.1. GE 1/0/0 and GE 1/0/1
both join VLAN 10 and IGMP SSM mapping is deployed on Router A.
It is required that IGMP snooping SSM mapping be configured on Switch A in the VLAN to
work jointly with IGMP SSM mapping. IGMP snooping SSM mapping also generates a mapping
between a multicast group and a multicast source. (*, G) information in IGMPv1 or IGMPv2
multicast data packets is then mapped to (S, G) information, providing SSM services for the
hosts running IGMPv1 or IGMPv2.

Figure 2-4 Networking diagram for configuring IGMP snooping SSM mapping
Source 2
10.1.1.2
Internet/
Source 1 Intranet
10.1.1.1
RouterA
GE1/0/0 Swtich
GE1/0/1
SwitchA
SSM Mapping
VLAN10
Host1 Host2
1. Configure basic IGMP snooping functions so that users can receive multicast data from
multicast sources.
2. Configure an SSM group policy for IGMP snooping to add the ASM group addresses of
users to the SSM group address range.
3. Configure IGMP snooping SSM mapping so that users can receive multicast data from a
specified multicast source.
Data Preparation
l VLAN 10 to which GE 1/0/0 and GE 1/0/1 on Switch A are added
l IGMPv3 run on Switch A and IGMPv2 run on Switch, Host 1, and Host 2
l Multicast source address 10.1.1.2
l Address of the multicast group to which GE 1/0/1 is statically added (224.1.1.1 is used in
this example)
Procedure
Step 1 Configure a VLAN.
<Quidway> system-view
[Quidway] sysname SwitchA
[SwitchA] vlan 10

[SwitchA-GigabitEthernet1/0/0] port hybrid pvid vlan 10
[SwitchA-GigabitEthernet1/0/0] port hybrid untagged vlan 10
Step 2 Enable global IGMP snooping and IGMP snooping in the VLAN.
[SwitchA] vlan 10
Step 3 Configure IGMPv3 on Switch A and configure IGMPv2 on hosts. The hosts are not allowed to
upgrade the IGMP version to 3.
[SwitchA-vlan10] igmp-snooping version 3
Step 4 Configure GE 1/0/0 as a static router interface in VLAN 10 and add GE 1/0/1 statically to
multicast group 224.1.1.1.
[SwitchA-GigabitEthernet1/0/0] igmp-snooping static-router-port vlan 10
Step 5 Configure an SSM group policy for IGMP snooping and enable IGMP snooping SSM mapping.
[SwitchA] acl number 2008
[SwitchA-acl-basic-2008] rule 5 permit source 224.1.1.1 0
[SwitchA-acl-basic-2008] quit
[SwitchA] vlan 10
[SwitchA-vlan10] igmp-snooping ssm-policy 2008
[SwitchA-vlan10] igmp-snooping ssm-mapping enable
[SwitchA-vlan10] igmp-snooping ssm-mapping 224.1.1.1 24 10.1.1.2

# Run the display igmp-snooping vlan configuration command on Switch A. You can view
IGMP snooping configurations in the VLAN.
[SwitchA] display igmp-snooping vlan configuration
IGMP Snooping Configuration for VLAN 10
igmp-snooping ssm-policy 2008
igmp-snooping ssm-mapping 224.1.1.0 255.255.255.0 10.1.1.2
# After SwitchA receives a Report message, run the display igmp-snooping port-info command
to view the configurations on the interface.
[SwitchA] display igmp-snooping port-info
-----------------------------------------------------------------------
-----------------------------------------------------------------------
VLAN 10, 1 Entry(s)
(10.1.1.2, 224.1.1.1) GE1/0/1 --M
1 port(s)
----End

Configuration Files
l Configuration file of Switch A
#
sysname SwitchA
#
vlan batch 10
#
#
acl number 2008
rule 5 permit source 224.1.1.1 0
#
vlan 10
igmp-snooping ssm-policy 2008
igmp-snooping ssm-mapping 224.1.1.0 255.255.255.0 10.1.1.2
#
port hybrid pvid vlan 10
port hybrid untagged vlan 10
igmp-snooping static-router-port vlan 10
#
l2-multicast static-group group-address 224.1.1.1 vlan 10
#
return

Configuration Guide - Multicast 3 Multicast VLAN Replication Configuration
3 Multicast VLAN Replication Configuration
About This Chapter
This chapter describes the procedure for configuring multicast VLAN replication and
maintenance commands, and provides configuration examples.
3.1 Multicast VLAN Replication Overview

After multicast VLAN replication is configured on a switch, the upstream router only needs to
transmit multicast data to a multicast VLAN. This function saves bandwidth because the
upstream router does not need to send a copy of multicast data to each user VLAN.
3.2 Multicast VLAN Replication Supported by the S9300
This section describes the multicast VLAN replication features supported by the S9300.
3.3 Configuring Multicast VLAN Replication Based on User VLANs
This section describes how to implement multicast VLAN replication based on user VLANs.
3.4 Configuring Multicast VLAN Replication Based on Interfaces
This section describes how to configure multicast VLAN replication based on interfaces.
3.5 Configuration Examples
This section provides configuration examples of multicast VLAN replication.

3.1 Multicast VLAN Replication Overview

After multicast VLAN replication is configured on a switch, the upstream router only needs to
transmit multicast data to a multicast VLAN. This function saves bandwidth because the
upstream router does not need to send a copy of multicast data to each user VLAN.
In traditional multicast transmission mode, the upstream router must copy multicast data for
each user VLAN and send all copies to the switch when users in different VLANs request the
program provided by the same multicast source. This mode wastes network bandwidth and adds
workload on the router.
When users in multiple VLANs require the program of the same multicast source, you can
configure the VLANs as the user VLANs of a multicast VLAN on the switch. The upstream
router only needs to send multicast data to the multicast VLAN and does not need to send a copy
to each user VLAN. When the switch receives multicast data packets from the upstream router,
it distributes multicast data packets to the user VLANs that have multicast receivers.
3.2 Multicast VLAN Replication Supported by the S9300

This section describes the multicast VLAN replication features supported by the S9300.
Multicast VLAN Replication Based on User VLANs

and reduces workload of the router
Figure 3-1 shows the traditional multicast data transmission mode. When HostA, HostB, and
HostC in different VLANs join the same multicast group, the Layer 3 device (router) must copy
multicast data for each VLAN and send all copies to the Layer 2 device (switch). This wastes
bandwidth and burdens the router.
Figure 3-1 Traditional multicast data transmission
Multicast Packet
VLAN 2 Receiver
VLAN 3 HostA
VLAN 4 VLAN 2
Receiver
HostB
Source Router Switch
VLAN 3
Receiver
HostC
VLAN 4

Figure 3-2 shows multicast data transmission after multicast VLAN replication is configured.
The router only needs to copy multicast data for the multicast VLAN and sends the data to the
switch. This saves network bandwidth and reduces workload of the router.
Figure 3-2 Multicast VLAN replication
Multicast Packet
Multicast VLAN Receiver
VLAN 2 HostA
VLAN 3 VLAN 2
VLAN 4
Receiver
HostB
Source Router Switch
VLAN 3
Receiver
HostC
VLAN 4
On the S9300, a multicast VLAN can have multiple user VLANs.
Multicast VLAN Replication Based on Interfaces

A carrier provides the multicast service for multiple Internet service providers (ISPs) and assigns
a multicast VLAN to each ISP to isolate multicast data and routes. The ISPs provide multicast
services for users on different interfaces. The interfaces may be added to the same user VLAN,
so multicast packets of an ISP may be sent to users that do not subscribe to services of this ISP.
To protect interests of ISPs, the carrier can bind user VLANs to multicast VLANs on the user-
side interfaces. As shown in Figure 3-3, after multicast VLANs are bound to user VLANs on
user-side interfaces, multicast data packets are only sent to user VLANs on the specified
interfaces.

Figure 3-3 Multicast data transmission before and after multicast VLAN replication is
configured on interfaces
Multicast Packet Multicast Packet
Multicast VLAN 2 Multicast VLAN 2
Multicast VLAN 3 Multicast VLAN 3
Router Router
Source
Source
Switch Switch
ISP1 ISP1
VLAN4 ISP2 VLAN4 ISP2
VLAN4 VLAN4
Receiver Receiver
HostA HostA HostA
HostA
3.3 Configuring Multicast VLAN Replication Based on User

VLANs
This section describes how to implement multicast VLAN replication based on user VLANs.
In traditional multicast transmission mode, a router must copy multicast data for each user VLAN
and send all copies to the downstream device when users in different VLANs request the program
provided by the same multicast source. This mode wastes network bandwidth and adds workload
on the router.
Multicast VLAN replication helps to manage and control the multicast source and the multicast
group members. This function enables users in different VLANs to receive the same multicast
flow and saves bandwidth.
In multicast VLAN replication implementation, VLANs are classified into multicast VLANs
and multiple user VLANs. The S9300 interface connected to a multicast source belongs to a
multicast VLAN, and interfaces connected to members of a multicast group belong to user
VLANs. The multicast VLAN aggregates multicast flows, and user VLANs receive data from
the multicast VLAN.

Before configuring multicast VLAN replication based on user VLANs, complete the following
tasks:
l Connecting interfaces and setting physical parameters for the interfaces to ensure that the
physical status of the interfaces is Up
Data Preparation
To configure multicast VLAN replication based on user VLANs, you need the following data.
No. Data
1 Multicast VLAN ID
2 User VLAN IDs
3.3.2 Configuring Multicast VLAN Replication Based on User

VLANs
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:

Step 4 Run:
multicast-vlan enable
Multicast VLAN replication is enabled, and the VLAN is configured as a multicast VLAN.
By default, multicast VLAN replication is disabled.
After IP multicast is configured on the S9300, no multicast VLAN can be configured.
Step 5 Run:
multicast-vlan user-vlan { { vlan-id1 [ to vlan-id2 ] } & <1-10> }
User VLANs are bound to the multicast VLAN.

The vlan-id1 and vlan-id2 parameters specify user VLAN IDs. The value of vlan-id2 must be
greater than the value of vlan-id1.
NOTE
The user VLANs specified in the command must be existing VLANs enabled with IGMP snooping and
cannot be multicast VLANs or user VLANs of another multicast VLAN.
----End
3.3.3 Adding Interfaces to VLANs
Procedure
Step 1 Run:
system-view

Step 2 Add a network-side interface to a multicast VLAN.
1. Run the interface interface-type interface-number command to enter the network-side
interface view.
2. Configure the network-side interface as a trunk or hybrid interface and add the interface to
the multicast VLAN. For the configuration procedure, see Dividing a LAN into VLANs
Based on Ports.
3. Run the quit command to return to the system view.
Step 3 Add a user-side interface to a user VLAN.
1. Run the interface interface-type interface-number command to enter the user-side interface
view
2. Configure the user-side interface as a trunk or hybrid interface and add the interface to the
user VLAN. For the configuration procedure, see Dividing a LAN into VLANs Based on
Ports.
----End
Prerequisite
The configuration of multicast VLAN replication is complete.
Procedure
l Run the display multicast-vlan vlan [ vlan-id ] command to view information about a
multicast VLAN.
----End
Example
Run the display multicast-vlan vlan [ vlan-id ] command to view information about a multicast
VLAN.

<Quidway> display multicast-vlan vlan 3

Multicast-vlan : 3
User-vlan Number : 2
IGMP snooping state : Enable
MLD snooping state : Disable
User-vlan Snooping-state
-----------------------------------------------
100 IGMP Enable /MLD Disable
200 IGMP Enable /MLD Disable
Run the display user-vlan vlan [ vlan-id ] command to view information about user VLANs.
<Quidway> display user-vlan vlan
Total user vlan 2
user-vlan snooping-state multicast-vlan snooping-state
---------------------------------------------------------
100 IGMP Enable /MLD Disable 3 IGMP Enable /MLD Disable
3.4 Configuring Multicast VLAN Replication Based on

Interfaces
This section describes how to configure multicast VLAN replication based on interfaces.
A carrier provides the multicast service for multiple Internet service providers (ISPs) and assigns
a multicast VLAN to each ISP to isolate multicast data and routes. The ISPs provide multicast
services for users on different interfaces. The interfaces may be added to the same user VLAN,
so multicast packets of an ISP may be sent to users that do not subscribe to services of this ISP.
To protect interests of ISPs, the carrier can bind user VLANs to multicast VLANs on the user-
side interfaces. Multicast data packets of a user VLAN are then sent to the specified interface.
Before configuring multicast VLAN replication based on interfaces, complete the following
tasks:
l Connecting interfaces and setting physical parameters for the interfaces to ensure that the
physical status of the interfaces is Up
Data Preparation
To configure multicast VLAN replication based on interfaces, you need the following data.
No. Data
1 Multicast VLAN ID
2 User VLAN IDs

No. Data
3.4.2 Creating a Multicast VLAN
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
----End
3.4.3 Binding User VLANs to a Multicast VLAN on an Interface
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
l2-multicast-bind vlan vlanid1 [ to vlanid2 ] mvlan mvlanid
User VLANs are bound to a multicast VLAN on the interface.

This command is used on user-side interfaces.
NOTE
After a user VLAN is bound to a multicast VLAN on an interface, Layer 2 multicast call admission control
(CAC) based on the interface and Layer 2 multicast CAC based on the interface and user VLAN do not
take effect on the interface. However, you can configure Layer 2 multicast CAC based on the interface and
a non-user VLAN.
The user VLANs must exist, and cannot be multicast VLANs or user VLANs of another multicast VLAN.
----End

3.4.4 Adding Interfaces to VLANs
Procedure
Step 1 Run:
system-view
Step 2 Add a network-side interface to a multicast VLAN.

1. Run the interface interface-type interface-number command to enter the network-side
interface view.
2. Configure the network-side interface as a trunk or hybrid interface and add the interface to
the multicast VLAN. For the configuration procedure, see Dividing a LAN into VLANs
Based on Ports.
3. Run the quit command to return to the system view.
Step 3 Add a user-side interface to a user VLAN.

1. Run the interface interface-type interface-number command to enter the user-side interface
view
2. Configure the user-side interface as a trunk or hybrid interface and add the interface to the
user VLAN. For the configuration procedure, see Dividing a LAN into VLANs Based on
Ports.
----End
Procedure
l Run the display l2-multicast-bind [ mvlan vlan-id ] command to view information about
a multicast VLAN and user VLANs bound to the multicast VLAN on an interface.
----End
Example
Run the display l2-multicast-bind [ mvlan vlan-id ] command to view information about a
multicast VLAN and its user VLANs.
<Quidway> display l2–multicast-bind mvlan 90
Port Startvlan Endvlan Mvlan
------------------------------------------------------------------
GigabitEthernet1/0/9 901 -- 90
Total Table(s) : 1

This section provides configuration examples of multicast VLAN replication.

3.5.1 Example for Configuring Multicast VLAN Replication Based

on User VLANs
As shown in Figure 3-4, RouterA is connected to the multicast source. GE1/0/0 of RouterA is
connected to GE1/0/0 of SwitchA. GE1/0/0 of SwitchA belongs to VLAN 10. HostA, HostB,
and HostC are connected to GE1/0/1, GE1/0/2, and GE1/0/3 of SwitchA and belong to VLAN
100, VLAN 200, and VLAN 300 respectively.
To save network bandwidth, you can configure multicast VLAN replication based on user
VLANs on SwitchA. RouterA then only needs to send one copy of multicast data to the multicast
VLAN, and SwitchA distributes multicast data to user VLANs.
Figure 3-4 Networking diagram for configuring multicast VLAN replication based on user
VLANs
Source GE1/0/0 RouterA
VLAN10
GE1/0/0 SwitchA
GE1/0/1 GE1/0/3
GE1/0/2
VLAN100 VLAN200 VLAN300
HostA HostB HostC

Reciever Reciever Reciever
1. Enable IGMP snooping globally.
2. Create a multicast VLAN and enable IGMP snooping in the multicast VLAN.
3. Create user VLANs.
4. Bind the user VLANs to the multicast VLAN.
5. Add the network-side interface and user-side interfaces to VLANs as hybrid interfaces.

Data Preparation
l Interface connected to RouterA and the VLAN that the interface belongs to
l User-side interfaces and the VLANs that the interfaces belong to
Procedure
Step 1 Enable IGMP snooping globally.
Step 2 Create a multicast VLAN and enable IGMP snooping in the multicast VLAN.
[SwitchA] vlan 10
[SwitchA-vlan3] multicast-vlan enable
Step 3 Create user VLANs and enable IGMP snooping in the user VLANs.
[SwitchA] vlan 100
[SwitchA] vlan 200
[SwitchA] vlan 300
Step 4 Bind user VLANs 100, 200, and 300 to multicast VLAN 10.
[Switch] vlan 10
[Switch-vlan3] multicast-vlan user-vlan 100 200 300
[Switch-vlan3] quit
Step 5 Add interfaces to VLANs as hybrid interfaces.

# Add GE1/0/0 to multicast VLAN 10.
[SwitchA] interface gigabitethernet1/0/0
# Add GE1/0/1 to VLAN 100, GE1/0/2 to VLAN 200, and GE1/0/3 to VLAN 300.
Step 6 Verify the configuration. View information about the multicast VLAN and user VLANs on
SwitchA.
[SwitchA] display multicast-vlan vlan
Total multicast vlan 1

multicast-vlan user-vlan number snooping-state

----------------------------------------------------------------
10 3 IGMP Enable /MLD Disable
[SwitchA] display user-vlan vlan

Total user vlan 3
user-vlan snooping-state multicast-vlan snooping-state
-----------------------------------------------------------------------------
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 100 200 300
#
#
vlan 10
multicast-vlan user-vlan 100 200 300
#
vlan 100
#
vlan 200
#
vlan 300
#
#
#
#
#
return
3.5.2 Example for Configuring Multicast VLAN Replication Based

on Interfaces
As shown in Figure 3-5, the Router is connected to the multicast source. GE1/0/0 of the Switch
A is connected to the Router. GE1/0/1 provides services for ISP1, and GE1/0/2 provides services

for ISP2. ISP1 and ISP2 use multicast VLAN 2 and VLAN 3 respectively to provide multicast
services for users. GE1/0/1 and GE1/0/2 belong to user VLAN 10.
To protect interests of the ISPs and ensure that multicast packets of each ISP are only sent to
users of the ISP, multicast VLANs and user VLANs can be bound on the user-side interfaces.
After the configuration is complete, multicast data of an ISP will be sent only to the interface
connected to the ISP.
Figure 3-5 Networking diagram for configuring multicast VLAN replication based on interfaces
Router GE1/0/0
Source
GE1/0/0
GE1/0/1
GE1/0/2
SwitchA
ISP1 ISP2
VLAN10 VLAN10
Receiver Receiver
HostA HostB
Mulcast Packet
Mulcast VLAN 2
Mulcast VLAN 3
1. Create multicast VLANs 2 and 3 and enable IGMP snooping in the multicast VLANs.
2. Create user VLAN 10.
3. Bind the user VLAN to multicast VLANs on GE1/0/1 and GE1/0/2.
4. Add the network-side interface and user-side interfaces to VLANs as hybrid interfaces.
Data Preparation
l Interface connected to the Router and the VLAN that the interface belongs to

l User-side interfaces and the VLANs that the interfaces belong to
Procedure
Step 1 Create multicast VLANs 2 and 3 and enable IGMP snooping in the multicast VLANs.
[SwitchA] vlan 2
[SwitchA] vlan 3
Step 2 Create user VLAN 10.

[SwitchA] vlan batch 10
Step 3 Bind the user VLAN to multicast VLANs on GE1/0/1 and GE1/0/2.
[SwitchA-GigabitEthernet1/0/1] l2-multicast-bind vlan 10 mvlan 2
[SwitchA-GigabitEthernet1/0/2] l2-multicast-bind vlan 10 mvlan 3
Step 4 Add GE1/0/0 to the multicast VLANs, and add GE1/0/1 and GE1/0/2 to the user VLAN.
# Add GE1/0/0 to multicast VLANs 2 and 3 as a trunk interface.

[SwitchA-GigabitEthernet1/0/0] port link-type trunk
[SwitchA-GigabitEthernet1/0/0] port trunk allow-pass vlan 2 3
# Add GE1/0/1 and GE1/0/2 to VLAN 10 as hybrid interfaces.

Run the display l2-multicast-bind [ mvlan vlan-id ] command on the Switch A to view binding
between user VLANs and multicast VLANs.
<SwitchA> display l2-multicast-bind vlan 10
-------------------------------------------------------------------
Port Startvlan Endvlan Mvlan
-------------------------------------------------------------------
-------------------------------------------------------------------
Total Table(s) : 2
----End

Configuration Files
l Configuration file of the Switch A
#
sysname SwitchA
#
vlan batch 2 3 10
#
#
vlan 2
#
vlan 3
#
port trunk allow-pass vlan 2 3
#
l2-multicast-bind vlan 10 mvlan 2
#
l2-multicast-bind vlan 10 mvlan 3
#
return

Configuration Guide - Multicast 4 IGMP Configuration
4 IGMP Configuration
About This Chapter
This chapter describes the procedure for configuring IGMP and commands for maintaining
IGMP, and provides configuration examples.
4.1 Introduction to IGMP

This section describes the principle of IGMP.
4.2 IGMP Features Supported by the S9300
This section describes IGMP features supported by the S9300.
4.3 Configuring Basic IGMP Functions
This section describes how to configure and apply IGMP.
4.4 Setting the Parameters of IGMP Features
This section describes how to set the parameters of IGMP features.
4.5 Configuring SSM Mapping
This section describes the applications of SSM mapping and the method of configuring SSM
mapping.
4.6 Configuration IGMP Limit Function
This section describes how to configure the IGMP limit function.
4.7 Maintaining IGMP
This section describes how to maintain IGMP.
This section provides several configuration examples of IGMP.

4.1 Introduction to IGMP

This section describes the principle of IGMP.
In the TCP/IP protocol suite, the Internet Group Management Protocol (IGMP) manages IPv4
multicast members. It sets up and maintains the multicast membership between IP hosts and
adjacent multicast routers.
As a routing switch, the S9300 supports IP multicast. When IGMP is configured, the S9300 can
be used as a multicast switch. IGMP is the signaling mechanism of the host towards the
S9300, which is used by IP multicast in an end user network. IGMP needs to be enabled on hosts
and on S9300s.
NOTE
l Whether the host supports IGMP depends on the used operating system.
l The switch mentioned in the following contents is an S9300 supporting the Layer 3 multicast protocol
and multicast router function.
l All receiver hosts that participate in multicast transmission must be enabled with IGMP.
A host can join or leave a multicast group at any time and from any position. The number
of members of a multicast group is not limited.
l Through IGMP, a multicast L3 device can know whether there is a multicast group receiver,
namely, a group member, on the network segment to which an interface of the router is
connected. Each host needs to save only the information about the groups that the host itself
joins.
At present, IGMP has three versions: IGMPv1 (defined by RFC 1112), IGMPv2 (defined by
RFC 2236), and IGMPv3 (defined by RFC 3376). All IGMP versions support the Any-Source
Multicast (ASM) model. IGMPv3 can be directly applied to the Source-Specific Multicast
(SSM) model, while IGMPv1 and IGMPv2 require the support of SSM mapping.
4.2 IGMP Features Supported by the S9300

This section describes IGMP features supported by the S9300.
Basic IGMP Functions

The basic IGMP features that the S9300 supports are as follows:
l Supporting IGMPv1, IGMPv2, and IGMPv3 and configurable version.
l Supporting the static IGMP.
l Configuring the range of multicast groups that an interface can join.
Router-Alert Option
IGMPv2 and IGMPv3 have the Group-Specific and Source/Group-Specific Query messages.
The groups are varied and an S9300 cannot join all groups. Therefore, the IGMP needs to use
the Router-Alert option. Then the IGMP can send messages for the groups that the local
S9300 does not join to the upper-level protocol for processing.
You can determine whether to set the Router-Alert option in the IGMP messages to be sent and
whether the received IGMP messages must contain the Router-Alert option.

IGMP Query Controller

For IGMPv1, you can set the interval for sending General Query messages and robustness
variable.
NOTE
IGMPv1 does not support querier election. Therefore, you need to enable PIM for querier election.
For IGMPv2, you can set the interval for sending General Query messages, robustness variable,
maximum response duration of IGMP Query messages, and IGMP prompt leave.
For IGMPv3, you can set the interval for sending General Query messages, robustness variable,
and maximum response time of IGMP Query messages.
SSM-Mapping
An S9300 can serve hosts of IGMPv1 and IGMPv2 after you configure SSM-Mapping on the
S9300.
IGMP Limit
l The function of IGMP Limit is applicable to IPv4 PIM-SM and IPv4 PIM-DM networks.
To limit the number of users accessing IP core networks, you can configure the IGMP limit
function.
– Configure the maximum number of global IGMP group memberships on a S9300.
– Configure the maximum number of IGMP group memberships on an interface.
NOTE
If the IGMP limit function is required to be configured globally, and for an interface on the same
S9300, it is recommended that the limits on the number of global IGMP group memberships, and the
number of IGMP group memberships on the interface should be in descending order.
4.3 Configuring Basic IGMP Functions

This section describes how to configure and apply IGMP.
IGMP is applied to the network segment in which a host is connected to an S9300. IGMP needs
to run on both the S9300 and the host. The following contents describe how to configure IGMP
on an S9300.
You must enable IP multicast routing before configuring IGMP. IP multicast routing is the
prerequisite of configuring all multicast functions. If IP multicast routing is disabled, the
multicast-related configurations cannot take effect.
IGMP needs to be enabled on the VLANIF interface that is connected to the host. The matching
IGMP version needs to be configured on the S9300 and host because the IGMP messages vary
according to version. The later version on the S9300 side is compatible with the earlier version
on the host side. Other configurations can be performed only after IGMP is enabled.

The host where the IGMP is run responds to the IGMP Query message of the S9300. If the host
gives no response and the operation times out, the S9300 considers that the multicast group does
not contain any member on the network segment and cancels data forwarding.
To enable hosts on the network segment of the interface to join the specified groups and receive
packets from the groups, you can set an ACL on the related interface to limit the range of groups
that the interface serves.
Before configuring basic IGMP functions, complete the following tasks:
l Configuring the parameters of the link layer protocol and the IP address of the interface to
enable the link-layer protocol
l Configuring the unicast routing protocol to ensure that IP routes between nodes are
reachable
Data Preparation
To configure basic IGMP functions, you need the following data.
No. Data
1 ID of the VLAN to which the interface

communicating with the host belongs
2 IGMP version
3 IP addresses of the multicast group and

multicast source
4 ACL rule for filtering multicast groups
4.3.2 Enabling IP Multicast
Context
The IP multicast function is the prerequisite of configuring other multicast protocols. Do as
follows on the S9300 connected to a host.
Procedure
Step 1 Run:
system-view


optimize the multicast forwarding table before enabling IP multicast routing.
Step 3 Run:
multicast routing-enable
IP multicast routing is enabled.
By default, the IP multicast routing function is disabled on an S9300
----End
4.3.3 Enabling the IGMP Function
Procedure
Step 1 Run:
system-view
Step 2 Run:
On the S9300, VLANIF interfaces, POS interfaces, IP-Trunk interfaces, and loopback interfaces
support IGMP.
Step 3 Run:
igmp enable
The IGMP function is enabled.
By default, the IGMP function is disabled on an interface.
----End
4.3.4 (Optional) Specifying the IGMP Version
Context
CAUTION
Make sure that all the interfaces on S9300s are configured with IGMP of the same version on
one network segment. By default, IGMPv2 is adopted.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The S9300 uses this interface to communicate with hosts. On the S9300, VLANIF interfaces,
POS interfaces, IP-Trunk interfaces, and loopback interfaces support IGMP.
Step 3 Run:
igmp version { 1 | 2 | 3 }
The IGMP version is specified on the interface.
----End
4.3.5 (Optional) Configuring a Static IGMP Group
Context
After an interface is added to a multicast group statically, the S9300 considers that multicast
group members exist on the network segment that the interface belongs to. Therefore, S9300
receives the multicast data sent to the multicast group.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
igmp static-group group-address [ source source-address ]
The interface is added to the multicast group or multicast source group statically.
If a loopback interface is used, the S9300 forwards the received data only when a user demands
the data. In this case, the bandwidth usage is reduced. If a VLANIF interface is adopted, the
S9300 forwards the received data directly.
If a loopback interface is used, the S9300 forwards the received data only when a user requests
the data. This reduces the CPU usage. VLANIF interfaces, POS interfaces, and IP-Trunk
interfaces forward multicast data immediately.
By default, an interface is not statically added to any multicast group.
----End

4.3.6 (Optional) Configuring an IGMP Multicast Group Policy
Context
To enable hosts on the network to which the interface is connected to join the specified multicast
groups and to receive messages from the groups, you need to set an ACL rule on the related
interface to filter the received messages. In this case, the range of groups that the interface serves
can be limited.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
igmp group-policy { acl-number | acl-name acl-name } [ 1 | 2 | 3 ]
The range of multicast groups that the interface can join is configured.
By default, an interface can join any multicast group.
----End
Prerequisite
The configuration of basic IGMP functions is complete.
Procedure
l Run the display igmp interface [ interface-type interface-number ] [ verbose ] command
to check the configuration and running status of IGMP on an interface.
l Run the display igmp group [ group-address | interface interface-type interface-
number ] * static command to check the information about the members of the static IGMP
multicast group.
l Run the display igmp group[ group-address | interface interface-type interface-
number ] * [ verbose ] command to check the information about the members that
dynamically join the IGMP multicast group.
----End

Example
Run the display igmp interface vlanif 3 command to check the configuration of IGMP on
VLANIF 3.
<Quidway> display igmp interface vlanif 3
Interface information
Vlanif10
(100.0.0.3):
IGMP is enabled
Current IGMP version is 2
IGMP state: up
IGMP group policy: none
IGMP limit: -
Value of query interval for IGMP (negotiated): -
Value of query interval for IGMP (configured): 60 s
Value of other querier timeout for IGMP: -
Value of maximum query response time for IGMP: 10 s
Querier for IGMP: 100.0.0.3 (this router)
Run the display igmp group static command to check the information about the static IGMP
multicast group.
<Quidway> display igmp group static
Static join group information
Total 2 entries, Total 2 active entries
Group Address Source Address Interface Expires
225.0.0.10 0.0.0.0 Loop1 never
232.1.1.20 10.0.0.1 Vlanif3 never
4.4 Setting the Parameters of IGMP Features

This section describes how to set the parameters of IGMP features.
Context
By default, IGMP can work normally. In the S9300, you can change the values of related
parameters according to the specific network environment. You can perform the following
configurations as required.
NOTE
l The configuration in the IGMP view is valid globally. The configuration in the interface view is valid
only for the specific interface.
l If this command is configured in the interface view and the IGMP view, the values set in the interface
view are preferred. If this command is not configured in the interface view, the values configured in
the IGMP view are valid.
IGMPv2 and IGMPv3 have the Group-Specific and Source/Group-Specific Query messages.
The groups are varied and an S9300 cannot join all groups. Therefore, the IGMP needs to use
the Router-Alert option. Then the IGMP can send messages for the groups that the local device
does not join to the upper protocol for processing.
The IGMP querier periodically sends IGMP Query messages on the shared network connected
to receivers. When receiving a Report message from a member, the querier updates information

about the membership. If non-queriers do not receive any General Query message within the
Keepalive period of the IGMP querier, the querier is considered faulty, and a new round of the
querier election is triggered automatically.
In some cases, one host matches a port. Therefore, a querier matches only one receiver host.
When a receiver host switches between multiple groups frequently, you can enable the prompt
leave mechanism on the querier.
Before configuring IGMP message options and timers, complete the following tasks:
l Configuring the unicast routing protocol to make the IP routes of nodes be reachable
l 4.3 Configuring Basic IGMP Functions
Data Preparation
To configure IGMP message options and related timers, you need the following data.
No. Data
1 Whether the Router-Alert option is contained

in the packet
2 Interval for sending IGMP General Query

messages
3 IGMP robustness variable
4 Maximum response duration of the IGMP

Query messages
5 Keepalive period of the other IGMP queriers
6 Interval for sending IGMP Group-Specific

Query messages
7 ACL that limits the application range of

prompt leave
4.4.2 Configuring IGMP Message Options
Context
The Router-Alert option requires the S9300 to send the received IGMP messages that have not
been added to IGMP groups to the upper layer protocol. By default, the S9300 sends IGMP
messages containing the Router-Alert option, but does not check the Router-Alert option in the
received messages. That is, the S9300 processes all the received IGMP messages, regardless
whether the messages contain the Router-Alert option. If require-router-alert is configured,
the S9300 checks this option.
The Router-Alert option can be configured globally or on an interface.

l The global configuration is valid on each interface.

l The configuration on an interface is valid only for the specific interface. The configuration
on an interface takes precedence over the global configuration. If the Router-Alert option
is not configured on the interface, the global configuration is used.
Procedure
l Configuring IGMP message options globally
1. Run:
system-view

2. Run:
igmp
The IGMP view is displayed.

3. Run:
require-router-alert
The S9300 is configured to ignore the IGMP messages that do not contain the Router-
Alert option.
4. Run:
send-router-alert
The S9300 is configured to add the Router-Alert option to the IGMP message header.
NOTE
After you run the send-router-alert command, information about the Router-Alert option will
not be displayed when you view the current configuration. To view information about the
Router-Alert option, run the undo send-router-alert command first.
l Configuring IGMP message options for the interface
1. Run:
system-view

2. Run:
The S9300 uses this interface to communicate with hosts. On the S9300, VLANIF
interfaces, POS interfaces, IP-Trunk interfaces, and loopback interfaces support
IGMP.
3. Run:
igmp require-router-alert
The S9300 is configured to ignore the IGMP messages that do not contain the Router-
Alert option.
4. Run:
igmp send-router-alert
The S9300 is configured to add the Router-Alert option to the IGMP message header.

NOTE
After you run the igmp send-router-alert command, information about the Router-Alert
option will not be displayed when you view the current configuration. To view information
about the Router-Alert option, run the undo igmp send-router-alert command first.
----End
4.4.3 Configuring the IGMPv1 Querier
Context
The IGMP querier can be configured globally or on an interface.
l The configuration on an interface is valid only for the specific interface. The configuration
on an interface takes precedence over the global configuration. If the IGMP querier is not
configured on the interface, the global configuration is used.
When the IGMP version is IGMPv1, the configurable parameters of the IGMP querier include
the interval for sending IGMP General Query messages and IGMP robustness variable.
Procedure
l Configuring the global IGMP querier
1. Run:
system-view

2. Run:
igmp

3. Run:
timer query interval
The interval for sending IGMP General Query messages is set.

4. Run:
robust-count robust-value
The IGMP robustness variable is set.

When the S9300 starts, the S9300 sends General Query messages robust-value times.
The interval between the messages is 1/4 of the interval for sending IGMP General
Query messages. By default, the robustness variable is 2.
l Configuring the IGMP querier on an interface
1. Run:
system-view

2. Run:

IGMP.
3. Run:
igmp timer query interval

4. Run:
igmp robust-count robust-value

When the S9300 starts, the S9300 sends General Query messages robust-value times.
The interval between the messages is 1/4 of the interval for sending IGMP General
Query messages. By default, the robustness variable is 2.
----End
4.4.4 Configuring the IGMPv2 or IGMPv3 Querier
Context
The IGMP querier can be configured globally or on an interface.
l The configuration on an interface is valid only for the specified interface. The configuration
on an interface takes precedence over the global configuration. If the IGMP querier is not
configured on the interface, the global configuration is used.
When the version of IGMP is IGMPv2 or IGMPv3, the configurable parameters of the IGMP
querier include the interval for sending IGMP General Query messages, interval for sending
IGMP Group-Specific Query messages, maximum response time for IGMP Query messages,
Keepalive period of other IGMP queriers, and IGMP robustness variable.
NOTE
In actual configuration, ensure that the interval for sending IGMP General Query messages is greater than
the maximum response time for IGMP Query messages and is smaller than the Keepalive period of other
IGMP queriers.
Procedure
l Configuring the IGMP querier globally
1. Run:
system-view

2. Run:
igmp

3. Run:


4. Run:
– When the system starts, the system sends General Query messages for a number
of times specified by the value of the robustness variable. The interval for sending
General Query messages is 1/4 of the interval for sending IGMP General Query
messages.
– When receiving a Leave message, the S9300 sends the IGMP Group-Specific
Query messages for the time specified by the value of the robustness variable at
the interval that you set.
5. Run:
max-response-time interval
The maximum response time for an IGMP Query message is set.

By default, the maximum response time for an IGMP Query message is 10 seconds.
6. Run:
timer other-querier-present interval
The Keepalive period of other IGMP queriers is set.

By default, the Keepalive period of other IGMP queriers = Robustness variable x
Interval for sending General Query messages + Maximum response time x 1/2. When
the values of the parameters in the formula are the default values, the Keepalive period
of other IGMP queriers is 125 seconds.
7. Run:
lastmember-queryinterval interval
The interval at which S9300 sends IGMP Group-Specific Query messages is set.
By default, the interval for sending IGMP Group-Specific Query messages is 1 second.
l Configuring the IGMP querier on an interface
1. Run:
system-view

2. Run:

IGMP.
3. Run:
igmp timer query interval

4. Run:
igmp robust-count robust-value

– When the system starts, the system sends General Query messages for a number
of times specified by the value of the robustness variable. The interval for sending
messages is 1/4 of the interval for sending IGMP General Query messages.
– When receiving a Leave message, the S9300 sends IGMP Group-Specific Query
messages for the time specified by the value of the robustness variable at the
interval that you set.
5. Run:
igmp max-response-time interval
The maximum response time for IGMP Query messages is set.

By default, the maximum response time for an IGMP Query message is 10 seconds.
6. Run:
igmp timer other-querier-present interval
The Keepalive period of other IGMP queriers is set.

By default, Keepalive period of other IGMP queriers = Robustness variable x Interval
for sending General Query messages + Maximum response time x 1/2. When the
values of the parameters to the right of the equal mark are the default values, the
Keepalive period of other IGMP queriers is 125 seconds.
7. Run:
igmp lastmember-queryinterval interval
The interval at which the S9300 sends IGMP Group-Specific Query messages is set.
By default, the interval for sending IGMP Group-Specific Query messages is 1 second.
8. Run:
igmp on-demand
The (S, G) entry never times out. The interface does not send IGMP Query messages.
By default, the interface sends Query messages and participates in querier election.
NOTE
Both IGMPv2 and IGMPv3 support the igmp on-demand command.
----End
4.4.5 Configuring IGMP Prompt Leave
Context
After receiving a Leave message from a host, the querier reports the message to the upstream
router instead of sending a Last Member Query message. This process is called IGMP prompt
leave. In this manner, the delay in response is reduced and the bandwidth occupied by various
messages is saved.

NOTE
l IGMP prompt leave is applicable only to IGMPv2.

l When the IGMP version is IGMPv1 or IGMPv3, the IGMP prompt leave does not take effect even
if there is information about this function in current configuration.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
igmp prompt-leave [ group-policy basic-acl-number ]
The S9300 leaves the group immediately without sending the Last Member Query message.
By default, the S9300 sends the Last Member Query message after receiving a Leave message
from a host.
----End
Prerequisite
The configuration of basic IGMP functions and parameters is complete.
Procedure
number ] * [ static | verbose ] command to check the information about members of an
IGMP multicast group.
to check the configuration and running status of IGMP on the interface.
l Run the display igmp routing-table [ group-address [ mask { group-mask | group-mask-
length } ] | source-address [ mask { source-mask | source-mask-length } ] ]* [ static ]
command to check the information about the IGMP routing table.
Run the preceding command, and you can obtain the following result:
– The membership information of the IGMP multicast group is correct.
– The configuration and running status of IGMP on an S9300 interface are correct.
– A matched multicast forwarding interface exists in the downstream list of the (*, G) or
(S, G) entry.
----End

Example
Run the display igmp group interface vlanif 3 static command, and you can view the IGMP
configuration on VLANIF 3.
<Quidway> display igmp group interface vlanif 3 static
Static join group information
Total 2 entries
Specified interface state:UP
Total 2 entries matched
Group Address Source Address Expires

232.1.1.1 10.0.0.1 never
225.0.0.10 0.0.0.0 never
Run the display igmp routing-table command, and you can view the IGMP routing table.
NOTE
The IGMP routing table is generated only after PIM is enabled.

<Quidway> display igmp routing-table
Total 1 entry
00001. (*, 225.0.0.10)

List of 1 downstream interface
Vlanif3 (100.0.0.3),
Protocol: STATIC

This section describes the applications of SSM mapping and the method of configuring SSM
mapping.
In the network segment where the SSM model is used to provide multicast services, some hosts
must run IGMPv1 or IGMPv2 because of some limitations. To provide services for these hosts,
you need to configure the SSM static mapping on S9300s.
Before configuring SSM mapping, complete the following tasks:
l Configuring the unicast routing protocol to ensure that the IP routes between nodes are
reachable
l 4.3.3 Enabling the IGMP Function
Data Preparation

No. Data
1 Interface that needs to be enabled with SSM

mapping
2 Addresses and masks of the multicast group

and multicast source
4.5.2 Enabling SSM Mapping
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
igmp enable
The IGMP function is enabled.

Step 4 Run:
igmp version 3
The version number of IGMP is set to 3.

To ensure that hosts running any IGMP version on the network segment can obtain SSM services,
it is recommended to run IGMPv3 on the S9300 interface.
Step 5 Run:
igmp ssm-mapping enable
SSM mapping is enabled.
----End
4.5.3 Configuring the SSM Mapping Policy
Procedure
Step 1 Run:
system-view

Step 2 Run:
igmp
Step 3 Run:
ssm-mapping group-address { mask | mask-length } source-address
An SSM group is mapped to a source.
The IP addresses of SSM groups range from 232.0.0.0 to 232.255.255.255. You can run the
command repeatedly to map an SSM group to multiple sources.
l group-address { mask | mask-length }: specifies the group address and mask.

l source-address: specifies the address of the source mapping the SSM group.
----End
Prerequisite
The configuration of SSM mapping is complete.
Procedure
number ]* ssm-mapping [ verbose ] command to check the address of a specific source or
group.
l Run the display igmp ssm-mapping { group [ group-address ] | interface [ interface-
type interface-number ] } command to check the information about SSM mapping of a
specific source or group.
----End
Example
Run the display igmp ssm-mapping group [ group-address ] command, and you can view the
information about SSM mapping of a specified group address.
<Quidway> display igmp ssm-mapping group 232.0.0.1
IGMP SSM-Mapping conversion table of VPN-Instance: public net
Total 2 entries 2 entries matched
00001. (10.0.0.1, 232.0.0.1)
00002. (10.0.0.2, 232.0.0.1)
Run the display igmp ssm-mapping interface interface-type interface-number command, and
you can view information about SSM mapping on a specified interface.
<Quidway> display igmp ssm-mapping interface vlanif 3
Info: IGMP SSM-Mapping is enabled

4.6 Configuration IGMP Limit Function

This section describes how to configure the IGMP limit function.
To limit IPTV ICPs and the number of users accessing IP core networks, you can configure the
IGMP limit function.
The IGMP limit function is configured on the last-hop S9300 connected to users. You can
perform the following configurations as required:
l Configure the maximum number of global IGMP group memberships on a S9300.
l Configure the maximum number of IGMP entries in a single instance.
l Configure the maximum number of IGMP group memberships on an interface.
Before configuring the IGMP limit function, complete the following task:
l Configuring a unicast routing protocol
l 4.3 Configuring Basic IGMP Functions
Data Preparation
To configure the IGMP limit function, you need the following data.
No. Data
1 Maximum number of global IGMP group memberships
2 Maximum number of IGMP group memberships in a single instance
3 Maximum number of IGMP group memberships on an interface
4.6.2 (Optional) Configuring the Maximum Number of Global

IGMP Group Memberships
Context
Do as follows on the S9300 connected to hosts.
Procedure
Step 1 Run:

system-view

Step 2 Run:
igmp global limit number
The maximum number of global IGMP entries of all instances is set.
----End
4.6.3 (Optional) Setting the Maximum Number of Global IGMP

Entries for an Instance
Context
Do as follows on the S9300 connected to user hosts.
Procedure
Step 1 Run:
system-view

Step 2 Run:
igmp [ vpn-instance vpn-instance-name ]

Step 3 Run:
limit number
The maximum number of global IGMP entries of an instance is set.
----End
4.6.4 (Optional) Configuring the Maximum Number of IGMP

Group Memberships on an Interface
Context
Do as follows on the S9300 connected to hosts.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The IGMP interface view is displayed.

Step 3 Run:
igmp limit number
The maximum number of IGMP group memberships is set on the interface.
----End
Procedure
to check the configuration and running of IGMP on an interface.
----End
4.7 Maintaining IGMP

This section describes how to maintain IGMP.
4.7.1 Clearing the Information About an IGMP Group
Context
CAUTION
The IGMP group that an interface dynamically joins is deleted after you run the reset igmp
group command. Receivers may not receive multicast information normally. Therefore, confirm
the action before run the command.
You can run the following commands to clear the information about an IGMP group in the user
view.
Procedure
l Run the reset igmp group { all | interface interface-type interface-number { all | group-
address [ mask { group-mask | group-mask-length } ] [ source-address [ mask { source-
mask | source-mask-length } ] ] } } command to clear the IGMP group that the interface
already dynamically joins.
----End
4.7.2 Monitoring the Running Status of IGMP

Context
To check the running status of IGMP during routine maintenance, run the following display
commands in any view.
Procedure
number ] [ static | verbose ] command to check the information about the IGMP multicast
group.
l Run the display igmp group ssm-mapping [ verbose ] command to check the information
about the multicast group that is already configured with SSM mapping.
to check the configuration and running status of IGMP on the interface.
l Run the display igmp routing-table [ group-address [ mask { group-mask | group-mask-
length } ] | source-address [ mask { source-mask | source-mask-length } ] ]* [ static ]
command to check the information about the IGMP routing table.
l Run the display igmp ssm-mapping { group [ group-address ] | interface [ interface-
type interface-number ] } command to check the information about SSM mapping of a
specific source or group.
----End
4.7.3 Debugging IGMP
Context
CAUTION
Procedure
l Run the debugging igmp { all | event | leave [ basic-acl-number ] | report [ advanced-
acl-number ] | query [ basic-acl-number ] | timer } command to enable the debugging of
IGMP.
l Run the debugging igmp ssm-mapping [ advanced-acl-number ] command to enable the
debugging of SSM mapping.
----End

This section provides several configuration examples of IGMP.
4.8.1 Example for Configuring Basic IGMP Functions

On the network as shown in Figure 4-1, the unicast routing function is normal. You are required
to implement multicast on the network to enable hosts to receive the Video On Demand (VOD)
information.
When the hosts connected to a certain interface need to receive a popular program for a long
time, you can add the interface to a multicast group statically. As shown in the following figure,
if HostA needs to receive the multicast data from the multicast group 225.1.1.1 for a long time,
you need to add GE 1/0/0 on the SwitchA to the multicast group 225.1.1.1 statically.
Figure 4-1 Networking diagram for configuring basic IGMP functions
Ethernet
HostA
SwitchA
Receiver
GE2/0/0 GE1/0/0 N1
HostB
SwitchB
Leaf
GE1/0/0
GE2/0/0 network
PIM HostC
network SwitchC Receiver
GE1/0/0 N2
GE2/0/0 HostD
Ethernet
Switch Physical interface VLANIF interface IP address

SwitchA GE 1/0/0 VLANIF 10 10.110.1.1/24
GE 2/0/0 VLANIF 11 192.168.1.1/24
SwitchB GE 1/0/0 VLANIF 20 10.110.2.1/24
GE 2/0/0 VLANIF 21 192.168.2.1/24
SwitchC GE 1/0/0 VLANIF 30 10.110.3.1/24
GE 2/0/0 VLANIF 31 192.168.3.1/24
1. Enable multicast on all Switches providing multicast services.

2. Enable PIM-SM on all the interfaces on Switch.
3. Enable IGMP on the interfaces on the host side.
4. Add VLANIF 10 on SwitchA to the multicast group 225.1.1.1 statically.
Data Preparation

l Version of IGMP running between Switches and hosts

l Static multicast group address: 225.1.1.1
NOTE
This configuration example describes only the commands used to configure IGMP.
Procedure
Step 1 Configure the IP addresses of interfaces and the unicast routing protocol on each Switch.
Configure the IP address and mask of each interface according to Figure 4-1. Configure OSPF
to ensure the communication between SwitchA, SwitchB, and SwitchC on the network layer,
and to ensure the dynamic update through the unicast routing protocol.
For details on how to configure IP addresses of interfaces, see OSPF Configuration in the
Quidway S9300 Terabit Routing Switch Configuration Guide - IP Service. For details on how
to configure OSPF, see IP Addresses Configuration in the Quidway S9300 Terabit Routing
Switch Configuration Guide - IP Routing.
Step 2 Enable multicast on all Switches and PIM-SM on all interfaces.
# Enable multicast on SwitchA and enable PIM-SM on all interfaces. The configurations of
SwitchB and SwitchC are similar to the configuration of SwitchA, and are not provided here.
[SwitchA] multicast routing-enable
[SwitchA] interface vlanif 10
[SwitchA-Vlanif10] pim sm
[SwitchA-Vlanif10] quit
Step 3 Enable IGMP on the interfaces connected to hosts.

# Enable IGMP on VLANIF 10 on SwitchA and configure the IGMP version as IGMPv2. The
configurations of SwitchB and SwitchC are similar to the configuration of SwitchA, and are not
provided here.
NOTE
By default, IGMPv2 is used and you do not need to set the IGMP version here. To use other IGMP versions,
run the igmp version command to set the version.
[SwitchA-Vlanif10] igmp enable
[SwitchA-Vlanif10] igmp version 2
Step 4 Add VLANIF 10 on SwitchA to the multicast group 225.1.1.1 statically. In this manner, the
hosts connected to VLANIF 10 can steadily receive the multicast data sent to the multicast group
225.1.1.1.
[SwitchA-Vlanif10] igmp static-group 225.1.1.1

# Run the display igmp interface command. You can check the configuration and running status
of IGMP on each interface. For example, the information about IGMP on VLANIF 10 of
SwitchA is as follows:
<SwitchA> display igmp interface vlanif 10
Interface information of VPN-Instance: public net

Vlanif 10(10.110.1.1):
IGMP is enabled
IGMP state: up
IGMP limit: -
Value of other querier timeout for IGMP: 0 s
# Run the display igmp routing-table command on SwitchA. You can check whether VLANIF
10 is added to the multicast group 225.1.1.1 statically. If the (*, 225.1.1.1) entry exists on
SwitchA, the downstream interface is VLANIF 10, and the protocol type is STATIC, you can
infer that VLANIF 10 is added to the multicast group 225.1.1.1 statically.
<SwitchA> display igmp routing-table
Routing table of VPN-Instance: public net
Total 1 entry
00001. (*, 225.1.1.1)
List of 1 downstream interface
Vlanif10 (10.110.1.1),
Protocol: STATIC
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 11
#
#
interface Vlanif10
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp static-group 225.1.1.1
#
interface Vlanif11
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface gigabitethernet 1/0/0
#
#
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
l Configuration file of SwitchB

#
sysname SwitchB
#
vlan batch 20 21

#
#
interface Vlanif20
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif21
ip address 192.168.2.1 255.255.255.0
pim sm
#
#
#
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
l Configuration file of SwitchC

#
sysname SwitchC
#
vlan batch 30 31
#
#
interface Vlanif30
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
#
#
#
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
4.8.2 Example for Configuring SSM Mapping
On the multicast network as shown in Figure 4-2, PIM-SM is run and ASM and SSM models
are used to provide multicast services. IGMPv3 is run on the interface on the Switch connected

to the Receiver. The IGMP version on the Receiver is IGMPv2 and cannot be upgraded to
IGMPv3.
The range of SSM group addresses on the current network is 232.1.1.0/24. S1, S2, and S3 send
multicast data to the multicast group whose IP address is in this range. The Receiver receives
the multicast data only from S1 and S3.
Solution: Configure SSM mapping on SwitchD.
Figure 4-2 Networking of the SSM mapping configuration

S2 S3
133.133.2.1/24 SwitchB SwitchC 133.133.3.1/24
GE1/0/0 GE3/0/0 GE3/0/0 GE1/0/0
GE2/0/0 GE2/0/0
PIM-SM
S1 Receiver
133.133.1.1/24 GE2/0/0 GE2/0/0 133.133.4.1/24
GE1/0/0 GE1/0/0
GE3/0/0 GE3/0/0
SwitchA SwitchD
Switch Physical interfaces VLANIF interface IP address

GE 2/0/0 VLANIF 20 192.168.1.1/24
GE 3/0/0 VLANIF 30 192.168.4.2/24
GE 2/0/0 VLANIF 20 192.168.1.2/24
GE 3/0/0 VLANIF 31 192.168.2.1/24
GE 2/0/0 VLANIF 21 192.168.3.1/24
GE 3/0/0 VLANIF 31 192.168.2.2/24
SwitchD GE 1/0/0 VLANIF 13 133.133.4.2/24
GE2/0/0 VLANIF 21 192.168.3.2/24
GE 3/0/0 VLANIF 30 192.168.4.1/24
1. Enable SSM mapping on the interfaces of the Switches connected to hosts.

2. Set the range of SSM group addresses on all the Switches in the PIM-SM domain.
3. Configure the static SSM mapping rules on the Switches where SSM mapping is enabled.
Data Preparation

l Range of SSM multicast groups

l IP addresses of Source 1 and Source 3
NOTE
This configuration example describes only the commands used to configure SSM mapping.
Procedure
Step 1 Create VLANs and add interfaces to the VLANs.
Step 2 Configure the IP address of each VLANIF and the unicast routing protocol according to Figure
4-2.
Step 3 Enable IGMP and SSM mapping on the interfaces connected to hosts.
[SwitchD] multicast routing-enable
[SwitchD] interface vlanif 10
[SwitchD-Vlanif10] igmp enable
[SwitchD-Vlanif10] igmp version 3
[SwitchD-Vlanif10] igmp ssm-mapping enable
[SwitchD-Vlanif10] quit
Step 4 Configure the range of SSM group addresses.

# Set the range of SSM group addresses to 232.1.1.0/24 on all Switches. The configurations of
SwitchB, SwitchC, and SwitchD are similar to configuration of SwitchA, and are not mentioned
here.
[SwitchA-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[SwitchA] pim
[SwitchA-pim] ssm-policy 2000
Step 5 Configure static SSM mapping rules on the Switches connected to hosts.
# Map the multicast group in the range of 232.1.1.0/24 to Source 1 and Source 3.
[SwitchD] igmp
[SwitchD-igmp] ssm-mapping 232.1.1.0 24 133.133.1.1
[SwitchD-igmp] ssm-mapping 232.1.1.0 24 133.133.3.1
# Check the information about SSM mapping of specific sources and group addresses on
Switches.
<SwitchD> display igmp ssm-mapping group
IGMP SSM-Mapping conversion table of VPN-Instance: public net
Total 2 entries 2 entries matched
00001. (133.133.1.1, 232.1.1.0)
00002. (133.133.3.1, 232.1.1.0)

# The Receiver joins the group 232.1.1.1.
# Run the display igmp group ssm-mapping command to view the information about the
specific sources or group addresses on the Switches. Take the information about the specific
source or group address on SwitchD for example:
<SwitchD> display igmp group ssm-mapping
IGMP SSM mapping interface group report information of VPN-Instance: public net
Vlanif10 (133.133.4.2):
Total 1 IGMP SSM-Mapping Group reported
Group Address Last Reporter Uptime Expires

232.1.1.1 133.133.4.1 00:01:44 00:00:26
<SwitchD> display igmp group ssm-mapping verbose

Interface group report information of VPN-Instance: public net
Vlanif10 (133.133.4.2):
Total entry on this interface: 1
Total 1 IGMP SSM-Mapping Group reported
Group: 232.1.1.1
Uptime: 00:01:52
Expires: 00:00:18
Last reporter: 133.133.4.1
Last-member-query-counter: 0
Last-member-query-timer-expiry: off
Group mode: exclude
Version1-host-present-timer-expiry: off
Version2-host-present-timer-expiry: 00:00:17
# Run the display pim routing-table command to view the PIM-SM multicast routing table on
a Switch. Take the information displayed on SwitchD for example:
<SwitchD> display pim routing-table
VPN-Instance: public net
Total 2 (S, G) entries
(133.133.1.1, 232.1.1.1)
RP: 192.168.3.2
Protocol: pim-sm, Flag:
UpTime: 00:11:25
Upstream interface: Vlanif30
Upstream neighbor: 192.168.4.2
RPF prime neighbor: 192.168.4.2
Downstream interface(s) information:
Total number of downstreams: 1
1: Vlanif13
Protocol: igmp, UpTime: 00:11:25, Expires:-
(133.133.3.1, 232.1.1.1)
RP: 192.168.3.2
Protocol: pim-sm, Flag:
UpTime: 00:11:25
1: Vlanif13
----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 133.133.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
#
#
#
#
ospf 1
area 0.0.0.0
network 133.133.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 133.133.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
#
#
#
#
ospf 1
area 0.0.0.0
network 133.133.2.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#

pim
ssm-policy 2000
#
return
#
sysname SwitchC
#
vlan batch 12 21 31
#
#
acl number 2000
#
interface Vlanif12
ip address 133.133.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
#
#
#
#
ospf 1
area 0.0.0.0
network 133.133.3.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
l Configuration file of SwitchD
#
sysname SwitchD
#
vlan batch 13 21 30
#
#
interface Vlanif13
ip address 133.133.4.2 255.255.255.0
pim sm
igmp enable
igmp version 3
igmp ssm-mapping enable
#
interface Vlaniaf21
ip address 192.168.3.2 255.255.255.0
pim sm
#

interface Vlanif30
ip address 192.168.4.1 255.255.255.0
pim sm
#
#
#
#
pim
ssm-policy 2000
#
acl number 2000
#
igmp
ssm-mapping 232.1.1.0 255.255.255.0 133.133.1.1
ssm-mapping 232.1.1.0 255.255.255.0 133.133.3.1
#
return
4.8.3 Example for Configuring IGMP Limit
When many users are watching multiple video programs, they occupy high bandwidth. As a
result, the device performance degrades and the multicast data received by users is unstable.
The traditional multicast technologies control the multicast networks by limiting the number of
multicast forwarding entries or the number of outgoing interfaces in a multicast forwarding entry.
These technologies, however, cannot flexibly manage the real-time video services or available
resources on the IPTV network.
The IGMP limit function allows users to plan network resources properly and limit the number
of multicast groups that users can join. As shown in Figure 4-3, the IGMP limit for the entire
system, an instance, and an interface needs to be configured on SwitchA, SwitchB, and
SwitchC connected to user hosts to limit the number of multicast groups that users can join.
When the number of users in a multicast group reaches the upper limit, no IGMP entry can be
created for the multicast group. This ensures that the multicast data received by the users in the
multicast group is stable.

Figure 4-3 Networking diagram of IGMP limit
Ethernet
HostA
SwitchA Receiver
N1
GE2/0/0
GE1/0/0
192.168.1.1/24 HostB
10.110.1.1/24
SwitchB GE1/0/0
GE2/0/0
192.168.2.1/24 10.110.2.1/24 Leaf network
HostC
PIM network
SwitchCGE1/0/0 Receiver
10.110.3.1/24 N2
HostD
GE2/0/0
192.168.3.1/24 Ethernet

SwitchA GE1/0/0 VLANIF10 10.110.1.1/24
GE2/0/0 VLANIF11 192.168.1.1/24
SwitchB GE1/0/0 VLANIF20 10.110.2.1/24
GE2/0/0 VLANIF21 192.168.2.1/24
SwitchC GE1/0/0 VLANIF30 10.110.3.1/24
GE2/0/0 VLANIF31 192.168.3.1/24
1. Enable multicast on all the switches providing multicast services. The multicast function
must be enabled before you enable IGMP.
2. Enable PIM-SM on all the VLANIF interfaces of the switches.
3. Enable IGMP on the VLANIF interfaces connected to user hosts.
4. Add GE1/0/0 of SwitchA to the multicast group 225.1.1.1 statically to enable user hosts to
receive stable multicast data.
5. Set the maximum number of IGMP group memberships on SwitchA.
Data Preparation
l Version of IGMP running between switches and user hosts

l Static multicast group address, 225.1.1.1
l Maximum number of member relationships in an IGMP group

Procedure
Step 1 Enable the multicast function and enable IGMP and PIM-SM on the user-side interfaces.
# Enable the multicast function on SwitchA, enable IGMP and PIM-SM on VLANIF 10, and
set the IGMP version to v2. The configurations of SwitchB and SwitchC are similar to the
configuration of SwitchA, and are not provided here.
[SwitchA-GigabitEthernet1/0/0] port hybrid tagged vlan 10
Step 2 Add GE1/0/0 of SwitchA to the multicast group 225.1.1.1 to enable the user hosts connected to
GE1/0/0 to receive stable multicast data sent to the multicast group 225.1.1.1.
[SwitchA-Vlanif10] igmp static-group 225.1.1.1
Step 3 Set the maximum number of member relationships in the IGMP group on the switch directly
connected to the user hosts.
# Set the maximum number of IGMP member relationships on SwitchA to 50.
[SwitchA] igmp global limit 50
# Set the maximum number of IGMP member relationships in the public network instance to
40.
[SwitchA] igmp
[SwitchA-igmp] limit 40
[SwitchA-igmp] quit
# Set the maximum number of IGMP member relationships on VLANIF 10 matching GE1/0/0
to 30.
[SwitchA-Vlanif10] igmp limit 30
# The configurations of SwitchB and SwitchC are similar to the configuration of SwitchA, and
are not provided here.
# Run the display igmp interface command to check the configuration and running status of
IGMP on each interface of the switch. The IGMP information on VLANIF 10 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
IGMP state: up
IGMP limit: 30
Value of other querier timeout for IGMP: 0 s

You can find that a maximum of 30 IGMP member relationships can be created on VLANIF 10
of SwitchA.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 11
#
igmp global limit 50
#
interface Vlanif10
igmp enable
igmp limit 30
ip address 10.110.1.1 24
#
interface Vlanif11
ip address 192.168.1.1 24
#
#
#
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
#
igmp limit 40
#
return

#
sysname SwitchB
#
vlan batch 20 21
#
#
interface Vlanif20
igmp enable
igmp limit 30
ip address 10.110.2.1 24
#
interface Vlanif21
ip address 192.168.2.1 24
#
#
#
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
#
igmp limit 40
#
return

#
sysname SwitchC
#
vlan batch 30 31
#
#
interface Vlanif30
igmp enable
igmp limit 30
ip address 10.110.3.1 24
#
interface Vlanif31
ip address 192.168.3.1 24
#
#
#
ospf 1
area 0.0.0.0
network 10.110.3.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
igmp limit 40
#
return

Configuration Guide - Multicast 5 PIM-DM (IPv4) Configuration
5 PIM-DM (IPv4) Configuration
About This Chapter
This chapter describes the PIM-DM (IPv4) fundamentals, configuration steps, and maintenance
for PIM-DM functions, along with typical examples.
5.1 PIM-DM Overview
In the network where multicast group members are densely distributed and each network
segment may have multicast group members, PIM-DM builds a unidirectional and loop-free
SPT from the multicast source to the group member through periodical flooding and pruning.
5.2 PIM-DM Features Supported by the S9300
The system can work normally with default PIM-DM parameters. You are also allowed to adjust
parameters related to neighbor discovery, prune, state refresh, graft, and assert according to
specific scenarios. In addition, you can configure various filtering policies and the PIM silent
function to enhance the PIM-DM security.
5.3 Configuring Basic PIM-DM Functions
Ensure that unicast routes are reachable before enabling IPv4 multicast routing, and enable PIM-
DM on each interface of the multicast device. In this manner, the PIM-DM network can work
normally.
5.4 Adjusting Control Parameters of a Multicast Source
A multicast device can control the forwarding of multicast data based on multicast sources. This
helps to control multicast data flows and limit information that can be obtained by downstream
receivers to enhance security.
5.5 Adjusting Control Parameters for Maintaining Neighbor Relationships
PIM devices exchange Hello messages to set up neighbor relationships and negotiate various
control parameters for controlling the neighbor relationships.
5.6 Adjusting Control Parameters for Prune
When the last member leaves a group, the multicast device sends a Prune message upstream,
requesting the upstream device to execute the prune action. If other downstream devices on the
same network segment need the multicast data for this group, they need to send Join messages
to override the prune action.
5.7 Adjusting Control Parameters for State-Refresh
In a PIM-DM network, the periodic flooding-pruning wastes lots of network resources. To
prevent the pruned interface from forwarding messages because the prune timer times out, you

can enable the State-Refresh function. The multicast device then sends State-Refresh messages
periodically to refresh the prune state of the interface and maintain the SPT.
5.8 Adjusting Control Parameters for Graft
To make new members in a network to quickly receive multicast data, a multicast device actively
sends a Graft message through an upstream interface, requesting the upstream device to forward
multicast data to this network segment.
5.9 Adjusting Control Parameters for Assert
If a multicast device can receive multicast data through an downstream interface, this indicates
that other upstream devices exist in this network segment. The device then sends an Assert
message through the downstream interface to take part in the election of the unique upstream
device.
5.10 Configuring PIM Silent
The interface directly connecting a multicast device to a user host needs to be enabled with PIM.
In this case, some malicious hosts may simulate a large number of PIM Hello messages and send
the messages to the interface for processing. As a result, the multicast device is suspended. To
avoid the preceding case, you can set the interface to be in the PIM Silent state.
5.11 Maintaining PIM-DM (IPv4)
Maintaining PIM-DM involves resetting PIM statistics, and monitoring PIM running status.
5.12 Configuration Example
Configuration examples are provided to show how to construct a basic PIM-DM network.

5.1 PIM-DM Overview

In the network where multicast group members are densely distributed and each network
CAUTION
This chapter is concerned only about the PIM-DM configuration in an IPv4 network.
The Protocol Independent Multicast (PIM) is a multicast protocol that is independent of unicast
routing protocol such as static route, RIP, OSPF, IS-IS, and BGP. Multicast routing is
independent of unicast routing protocols, except that unicast routing protocols are used to
generate related multicast routing entries.
Based on the Reverse Path Forwarding (RPF), PIM transmits multicast data across a network.
RPF constructs a multicast forwarding tree by using the existing unicast routing information.
When a multicast packet reaches a switch, the switch performs the RPF check first. If the packet
does not pass the RPF check, the switch directly discards the packet.
NOTE
For details about RPF, see IPv4 Multicast Routing Management.
The Protocol Independent Multicast-Dense Mode (PIM-DM) is applicable to a small-scale

network with densely-distributed members.
The functions and location of PIM-DM in a multicast network are shown in Figure 5-1.
Figure 5-1 Location of PIM-DM on the multicast network
IGMP
Receiver
UserA
PIM-DM
Source
Receiver
UserB
Multicast
PIM-DM
Server
PIM-DM IGMP Receiver
UserC
Receiver
UserD

The Protocol Independent Multicast-Sparse Mode (PIM-SM) is applicable to a large-scale

network with sparsely-distributed members. For details about PIM-SM, see PIM-SM (IPv4)
Configuration.

function to enhance the PIM-DM security.
Controlling the Forwarding of a Multicast Source

You can configure the Keepalive period of a multicast source and the filtering rules based on
multicast sources.
Adjusting Control Parameters for Setting Up Neighbor Relationship

You can set the following control parameters:
l The interval for sending Hello messages

l The period for keeping neighbors reachable
l Whether the Hello messages without the Generation ID option are received
l The maximum delay for triggering Hello messages
l Neighbor filtering function: An interface sets up neighbor relationships with only the
addresses matching the filtering rules and deletes the neighbors unmatched with the filtering
rules
Adjusting Control Parameters for Pruning

You can adjust the following control parameters for pruning:
l The interval for keeping the Prune state of the downstream interface
l The delay from the time when the current switch receives a Prune message from a
downstream switch to the time when the current switch performs the prune action in the
LAN
l The period for overriding the prune action
Adjusting Control Parameters for State-Refresh

You can enable or disable State-Refresh, set the interval for sending PIM State-Refresh
messages, set the minimum interval for receiving the next State-Refresh message, and set the
TTL value for forwarding State-Refresh messages on the switch directly connected to the source.
Adjusting Control Parameters for Graft

You can set the interval for retransmitting Graft messages.

Adjusting Control Parameters for Assert

You can set the period for a switch to retain the Assert state. The switch that fails in the election
prevents the downstream interface from forwarding multicast data during this period. After the
period expires, the downstream interface continues to forward multicast data.
Attack Defense Using PIM Silent

Some hosts may send a large number of malicious PIM Hello messages, which results in the
suspension of the switch. The PIM Silent function can then be configured on the interfaces
connected to hosts to protect the switch.
PIM Multi-instance
In multi-instance applications, multicast switchs need to maintain the PIM neighbor list and
multicast routing table for different VPN instances and keep the information independent among
multiple instances.
When a switch receives a multicast data packet, the switch needs to distinguish the VPN instance
to which the packet belongs and forward the packet based on the multicast routing table of the
specific VPN instance, or create a PIM multicast routing entry of the VPN instance.
5.3 Configuring Basic PIM-DM Functions

Ensure that unicast routes are reachable before enabling IPv4 multicast routing, and enable PIM-
DM on each interface of the multicast device. In this manner, the PIM-DM network can work
normally.

Before configuring basic PIM-DM functions, configure a unicast IPv4 routing protocol.
PIM-DM is applicable to a small-scale network, and most network segments of the network have
receivers.
Before configuring basic PIM-DM functions, complete the following configuration tasks:
l Configuring an IPv4 unicast routing protocol
Data Preparation
To configure basic PIM-DM functions, you need the following data.
No. Data
1 Type and number of an interface

5.3.2 Enabling IPv4 Multicast Routing

Prior to configuring all IPv4 multicast features, enable IPv4 multicast routing.
Context
CAUTION
The configuration related to the VPN instance is applicable only to the PE switch. If the interface
of the VPN instance connects to hosts, run the commands in Step 3 and Step 4.
Do as follows on the switch:
Procedure
Step 1 Run:
system-view

optimize the multicast forwarding table before enabling IPv4 multicast routing.
Step 3 Run:
IPv4 multicast routing is enabled in the public network.

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

IPv4 multicast routing is enabled in the VPN instance.
----End
5.3.3 Enabling PIM-DM

An interface can set up PIM neighbor relationship with other devices after PIM-DM is enabled
on it.

Context
NOTE
PIM-SM and PIM-DM cannot be enabled on an interface at the same time. The PIM mode must be the
same on all the interfaces of the same instance. When switches are distributed in different PIM-DM
domains, enable PIM-SM on all non-boundary interfaces.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The interface can be a VLANIF interface, an Loopback interface, a POS interface, or an IP-
Trunk interface.
Step 3 Run:
pim dm
PIM-DM is enabled.
After PIM-DM is enabled on the interface and the PIM neighbor relationship is set up between
switches, the protocol packets sent by the PIM neighbors can be processed. You can run the
undo pim dm command to disable PIM-DM on the interface.
----End

After PIM-DM is configured successfully, you can check information about the PIM interface,
PIM neighbor, and PIM routing table through commands..
Procedure
l Run the command display pim [ vpn-instance vpn-instance-name | all-instance ]
interface [ interface-type interface-number | up | down ] [ verbose ] to check PIM on
interfaces of the public network, VPN instance, or all instances.
neighbor [ neighbor-address | interface interface-type interface-number | verbose ] * to
check PIM neighbors of the public network, VPN instance, or all instances.
l Run the following commands to check the PIM routing table of the public network, VPN
instance, or all instances.
– 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 { dm | sm | ssm } | flags flag-value | fsm ]

* [ outgoing-interface-number [ number ] ]
– 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 | vpn-instance vpn-
instance-name | register | none } | mode { dm | sm | ssm } | flags flag-value | fsm ] *
[ outgoing-interface-number [ number ] ]
– 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 } ] *
----End
Example
Run the display pim interface verbose command, and you can view the detailed information
about PIM on the interface in the public network instance.
<Quidway> display pim interface verbose
Interface: Vlanif117, -
PIM version: 2
PIM mode: Dense
PIM state: down
PIM DR: -
PIM DR Priority (configured): 1
PIM neighbor count: -
PIM hello interval: 30 s
PIM LAN delay (negotiated): -
PIM LAN delay (configured): 500 ms
PIM hello override interval (negotiated): -
PIM hello override interval (configured): 2500 ms
PIM Silent: disabled
PIM neighbor tracking (negotiated): -
PIM neighbor tracking (configured): disabled
PIM generation ID: -
PIM require-GenID: disabled
PIM hello hold interval: 105 s
PIM assert hold interval: 180 s
PIM triggered hello delay: 5 s
PIM J/P interval: 60 s
PIM J/P hold interval: 210 s
PIM state-refresh processing: enabled
PIM state-refresh interval: 60 s
PIM graft retry interval: 3 s
PIM state-refresh capability on link: capable
PIM BFD: disabled
PIM dr-switch-delay timer : not configured
Number of routers on link not using DR priority: -
Number of routers on link not using LAN delay: -
Number of routers on link not using neighbor tracking: -
ACL of PIM neighbor policy: -
ACL of PIM ASM join policy: -
ACL of PIM SSM join policy: -
5.4 Adjusting Control Parameters of a Multicast Source



After basic functions of PIM-DM are configured, you can configure the lifetime of a multicast
source and source address-based filtering rules as required.
This configuration is applicable to all PIM-DM networks.
A PIM switch checks the passing multicast data. By checking whether the data matches the
filtering rule, the switch determines whether to forward the data. In this case, you can regard the
switch as the filter of the multicast data. The filter helps to control the data flow and limit the
information that downstream receivers can obtain. Network security is thus ensured.
Before configuring control parameters of a multicast source, complete the following tasks:

l Configuring Basic PIM-DM Functions
Data Preparation
To configure control parameters of a multicast source, you need the following data.
No. Data
1 Keepalive period of a multicast source
2 Filtering rules of multicast source addresses
5.4.2 Configuring the Lifetime of a Source

A multicast device starts a timer for each (S, G) entry. If the multicast device does not receive
any multicast packets from a multicast source within the set lifetime of the multicast source, it
considers that the (S, G) entry becomes invalid and the multicast source stops sending multicast
data to the multicast group.
Context
Do as follows on the PIM switch:
NOTE
If there is no special requirement, default values are recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim [ vpn-instance vpn-instance-name ]
The PIM view is displayed.
Step 3 Run:
source-lifetime interval
The lifetime of a source is set.
If a switch does not receive any (S, G) packet in the lifetime of the source, the switch considers
that the source stops sending multicast data to G and the (S, G) entry becomes invalid.
When State-Refresh is enabled, the lifetime of the multicast source is prolonged to about the
value of interval.
----End
5.4.3 Configuring Filtering Rules Based on Source Addresses

After ACL rules are configured, a multicast device can filter the received multicast packets based
on source addresses or source/group addresses.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
source-policy { acl-number | acl-name acl-name }
The filter is configured.
The effect of the filtering is more obvious if the filter is closer to the source.
l If the basic ACL is configured, only the packets with the source addresses that pass the
filtering are forwarded.
l If the advanced ACL is configured, only the packets with the source addresses and group
addresses that pass the filtering are forwarded.

NOTE
l If acl-number | acl-name acl-name is specified in the source-policy command and ACL rules are
created, only the multicast packets whose source addresses match the ACL rules are permitted.
l If acl-number | acl-name acl-name is specified in the source-policy command and no ACL rule is
created, the multicast packets with any source addresses are not forwarded.
l The source-policy command does not filter the static (S, G) entries and the PIM entries of the Join
messages received from private networks.
----End

After the control parameters of a multicast source are adjusted, you can run commands to check
entries in the PIM routing table.
Procedure
l Run the following commands to check the PIM routing table.

----End
5.5 Adjusting Control Parameters for Maintaining Neighbor

Relationships
PIM devices exchange Hello messages to set up neighbor relationships and negotiate various
control parameters for controlling the neighbor relationships.

After basic functions of PIM-DM are configured, you can adjust related parameters of Hello
messages for controlling the neighbor relationships, and configure the neighbor filtering function
to enhance security as required.

PIM switchs exchange Hello messages to set up neighbor relationships and negotiate various
control parameters.
The Switch under the control of default values can work normally. In the S9300, users can adjust
related parameters according to the specific network environment.
NOTE
Before adjusting control parameters for maintaining neighbor relationships, complete the
following tasks:

Data Preparation
To adjust control parameters for maintaining neighbor relationships, you need the following
data.
No. Data
1 Timeout period of the neighbor
2 Interval for sending Hello messages
3 Maximum delay for triggering Hello messages
4 Number or name of the ACL used to filter PIM neighbors
5.5.2 Configuring the Interval for Sending Hello Messages

The interval for sending Hello messages can be set either globally or on an interface. The
configuration in the interface view is prior to the configuration in the PIM view. When the
interval is not configured in the interface view, the configuration in the PIM view takes effect.
Context
Do as follows on the PIM-DM switch:
NOTE
The configuration involves the following cases:

l Global configuration: It is valid on each interface.
l Configuration on an interface: The configuration on an interface takes precedence over the global
configuration. If the configuration on an interface is not done, the global configuration is used.

Procedure
l Global Configuration
1. Run:
system-view

2. Run:

3. Run:
timer hello interval
The interval for sending Hello messages is set.

l Configuration on an Interface
1. Run:
system-view

2. Run:
The interface can be a VLANIF interface, an Loopback interface, a POS interface, or

an IP-Trunk interface.
3. Run:
pim timer hello interval

4. Run:
pim triggered-hello-delay interval
The maximum delay for triggering Hello messages is set.
After the maximum delay is set, the conflict caused by multiple PIM switchs sending
Hello messages simultaneously is prevented.
----End
5.5.3 Configuring the Timeout Period of a Neighbor

The timeout period of a neighbor can be set either globally or on an interface. If the multicast
device does not receive any Hello message from a neighbor when the timeout period is expired,
the device considers that the neighbor is unreachable. The timeout period of the neighbor must
be longer than the interval for sending Hello messages.
Context

NOTE
The configuration involves the following two cases:

Procedure
1. Run:
system-view

2. Run:

3. Run:
hello-option holdtime interval
The timeout period during which the neighbor is reachable is set.
If no Hello message is received from a neighbor in the timeout period, the neighbor
is considered unreachable.
1. Run:
system-view

2. Run:

3. Run:
pim hello-option holdtime interval
The timeout period during which the neighbor is reachable is set.
If no Hello message is received from a neighbor in the timeout period, the neighbor
is considered unreachable.
----End
5.5.4 Refusing to Receive the Hello Message Without the

Generation ID Option
When the Generation ID option in the Hello message received from an upstream neighbor
changes, it indicates that the status of the upstream neighbor changes. Therefore, you can
configure a PIM interface to deny the Hello messages without Generation ID options to obtain
the upstream neighbor status in real time.

Procedure
Step 1 Run:
system-view

Step 2 Run:

Trunk interface.
Step 3 Run:
pim require-genid
The Generation ID option is set in a Hello message.

The Hello message without the Generation ID option is rejected.
changes, it indicates that the upstream neighbor restarts. If a switch does not want to receive
data from an upstream neighbor, the switch sends a Prune message after receiving a data packet
from the upstream neighbor.
----End
5.5.5 Configuring PIM Neighbor Filtering

To prevent some unknown devices from being involved in PIM, filtering PIM neighbors is
required. An interface sets up neighbor relationships with only the addresses matching the
filtering rules and deletes the neighbors unmatched with the filtering rules.
Context
To prevent some switch from being involved in PIM, filtering PIM neighbors is required.
Do as follows on the switch running PIM-DM:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Trunk interface.
Step 3 Run:
pim neighbor-policy { basic-acl-number | acl-name acl-name }

PIM neighbor filtering is configured.
An interface sets up neighbor relationships with only the addresses matching the filtering rules
and deletes the neighbors unmatching the filtering rules.
NOTE
When configuring the neighbor filtering function on the interface, you must also configure the neighbor
filtering function correspondingly on the switch that sets up the neighbor relationship with the interface.
----End

After the neighbor control parameters are adjusted, you can run commands to check information
about the PIM interface and the PIM neighbor.
Procedure
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] interface
[ interface-type interface-number | up | down ] [ verbose ] command to check PIM 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 a PIM neighbor.
----End

requesting the upstream device to execute the prune action. If other downstream devices on the
same network segment need the multicast data for this group, they need to send Join messages
to override the prune action.

After basic PIM-DM functions are configured, you can set the period for an interface to keep
the prune state, delay for transmitting Prune messages in a LAN, and interval for overriding the
prune action as required.
When the last member leaves its group, the switch sends a Prune message through an upstream
interface. After receiving the Prune message, the upstream switch performs the prune action and
stops sending multicast packets to this network segment. If other downstream switchs exist in
the network, the switchs need to send a Join message to override the prune action.
Switchs can work normally under the control of the default parameter values. Users can adjust

NOTE

Before adjusting control parameters for prune, complete the following tasks:
Data Preparation
To adjust control parameters for prune, you need the following data.
No. Data
1 Timeout period of the Prune state
2 Delay for transmitting Prune messages
3 Period for overriding the prune action
5.6.2 Configuring the Period for an Interface to Keep the Prune State
The period for an interface to keep the prune state can be set either globally or on an interface.
After the period expires, the pruned interface starts to forward messages again. If the multicast
device receives a State-Refresh message before the period expires, it resets the timer, that is, it
refreshes the prune state.
Context
Procedure
1. Run:
system-view

2. Run:

3. Run:
holdtime join-prune interval
The period during which the downstream interface is in the Prune state is set.

After the period expires, the pruned interface starts to forward packets again. Before
the period expires, the switch refreshes the Prune state when receiving a State-Refresh
message.
1. Run:
system-view

2. Run:

3. Run:
pim holdtime join-prune interval
After the period is expired, the pruned interface starts to forward packets again.
Before the period expires, the switch refreshes the Prune state when receiving a State-
Refresh message.
----End
5.6.3 Configuring the Delay for Transmitting Prune Messages in a

LAN
The delay for transmitting Prune messages in a LAN can be set either globally or on an interface.
When the values of lan-delay on all devices along the same link are different, the maximum
value of these values is preferred.
Context
Procedure
1. Run:
system-view

2. Run:

3. Run:
hello-option lan-delay interval
The delay for transmitting messages in a LAN is set.


1. Run:
system-view

2. Run:

3. Run:
pim hello-option lan-delay interval

----End
5.6.4 Configuring the Interval for Overriding the Prune Action

If a device receives a Prune message from the upstream interface, it indicates that other
downstream devices still exist in the LAN. If these devices still needs to receive the multicast
data, the device must send a Join message upstream within the override-interval.
Context
Procedure
1. Run:
system-view

2. Run:

3. Run:
hello-option override-interval interval
The interval for overriding the prune action is set.

When a switch receives a Prune message from an upstream interface, it indicates that
another downstream switch exists in the LAN. If the switch still requests the multicast
data, it needs to send a Join message to the upstream switch in the override-interval
period.
1. Run:
system-view

2. Run:


3. Run:
pim hello-option override-interval interval

----End

After the control parameters for prune are adjusted, you can check information about the PIM
interface and the PIM routing table and statistics about PIM control messages through
commands.
Procedure
[ interface-type interface-number | up | down ] [ verbose ] command to check information
about PIM on an interface.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] control-message
counters [ message-type { assert | graft | graft-ack | hello | join-prune | state-refresh |
bsr } | interface interface-type interface-number ] * command to check the number of sent
or received PIM control packets.

----End

can enable the State-Refresh function. The multicast device then sends State-Refresh messages
periodically to refresh the prune state of the interface and maintain the SPT.


After basic functions of PIM-DM are configured, you can set the interval for sending State-
Refresh messages, period for waiting to receive the next State-Refresh message, and TTL value
carried in the State-Refresh message as required.
In a PIM-DM network, periodical flooding-prune wastes a lot of network resources. To prevent
a pruned interface from forwarding packets, you can enable the State-Refresh function.
Switch periodically send State-Refresh messages to refresh the prune state of interfaces and
maintain the SPT.
NOTE
If there is no specific requirement, default values are recommended.
Before adjusting control parameters for State-Refresh, complete the following tasks:

Data Preparation
To adjust control parameters for State-Refresh, you need the following data.
No. Data
1 Interval for sending PIM State-Refresh messages
2 Period for waiting to receive the next State-Refresh message
3 TTL value for forwarding State-Refresh messages
5.7.2 Disabling State-Refresh

After this function is disabled on the interface, the interface cannot forward any State-Refresh
messages.
Context
Do as follows on all the switchs in the PIM-DM domain.
NOTE
By default, PIM-DM State-Refresh is enabled on the interface.

Procedure
Step 1 Run:
system-view
Step 2 Run:
Trunk interface.
Step 3 Run:
undo pim state-refresh-capable
PIM-DM State-Refresh is disabled.
The interface on which PIM-DM State-Refresh is disabled cannot forward any State-Refresh
message.
NOTE
You can run the pim state-refresh-capable command to re-enable PIM-DM State-Refresh on the interface.
----End
5.7.3 Configuring the Interval for Sending State-Refresh Messages

To prevent pruned interfaces from forwarding messages after the prune state timer times out,
you need to set the interval for sending State-Refresh messages to be shorter than the period for
keeping the Prune state.
Context
Do as follows on all the switchs in the PIM-DM domain:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
state-refresh-interval interval
The interval for sending PIM State-Refresh messages is set.

NOTE
l This command is applicable to the first-hop switch connecting with the multicast source.
l The interval for sending PIM State-Refresh messages should be shorter than the timeout period for
l You can run the holdtime join-prune command to set the timeout period for keeping the Prune state.
----End
5.7.4 Configuring the Period for Receiving the Next State-Refresh

Message
A multicast device may receive PIM State-Refresh messages from multiple routers in a short
period and some PIM State-Refresh messages are repeated. Before the state-refresh timer times
out, the device discards the received repeated State-Refresh messages. The device is allowed to
receive the next State-Refresh message only after the timer times out.
Context
Do as follows on all the PIM-DM switchs in the PIM-DM domain:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
state-refresh-rate-limit interval
The period for waiting to receive the next State-Refresh message is set.
----End
5.7.5 Configuring the TTL Value Carried in a State-Refresh

Message
After receiving the PIM State-Refresh message, a multicast device decrements the TTL value
by 1 and then forwards the message downstream until the TTL value becomes 0. In a small-
sized network, the PIM State-Refresh message is transmitted circularly on the network. You can
adjust the TTL value according to the network scale.
Context
Do as follows on all the PIM-DM switchs in the PIM-DM domain:

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
state-refresh-ttl ttl-value
The TTL value carried in the State-Refresh message is set.
NOTE
This command is valid only on the switch directly connected to the source.
----End

After the control parameters for state-refresh are adjusted, you can check information about the
PIM interface and the PIM routing table and statistics about PIM control messages through
commands.
Procedure
interface.
or received PIM control messages.



----End
5.8 Adjusting Control Parameters for Graft

To make new members in a network to quickly receive multicast data, a multicast device actively
sends a Graft message through an upstream interface, requesting the upstream device to forward
multicast data to this network segment.

After basic functions of PIM-DM are configured, you can set the interval for retransmitting Graft
messages as required.
In a PIM-DM network, if State-Refresh is not enabled, a pruned interface can forward packets
after the Prune state times out. If State-Refresh is enabled, the pruned interface may never
forward packets.
To enable new members in the network to receive multicast data quickly, a PIM-DM switch
sends a Graft message through an upstream interface. After receiving the Graft message, the
upstream switch responds immediately with a Graft-Ack message and enables the interface that
receives the Graft message to forward packets.
the related parameters according to the specific network environment.
NOTE
Pre-configuration Task
Before configuring control parameters for graft, complete the following tasks:
Data Preparation
To configure control parameters for graft, you need the following data.
No. Data
1 Interval for retransmitting Graft messages
5.8.2 Configuring the Interval for Retransmitting Graft Messages

In PIM-DM mode, when a member joins a pruned group, the multicast device sends a Graft
message and waits for an ACK message from the upstream device. If the downstream device

does not receive any ACK message within a certain period, the device resends the Graft message
until it receives an ACK message from the upstream device.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Trunk interface.
Step 3 Run:
pim timer graft-retry interval
The interval for retransmitting Graft messages is set.
If the local switch does not receive any Graft-Ack message from the upstream switch in a
specified period, it resends a Graft message.
----End

After the control parameters for graft are adjusted, you can check information about the
unacknowledged PIM-DM graft, PIM interface, and PIM routing table and statistics about PIM
control messages through commands.
Procedure
interface.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] grafts command
to check an unacknowledged PIM-DM graft.
bsr } | interface interface-type interface-number ] * command to check the number of the
sent or received PIM control messages.



----End

If a multicast device can receive multicast data through an downstream interface, this indicates
device.

After basic functions of PIM-DM are configured, you can set the holdtime of the Assert state as
required.
When a PIM-DM switch receives multicast data through a downstream interface, it indicates
that other upstream switchs exist in the network segment. The switch sends Assert messages
through the interface to elect the unique upstream switch.
NOTE
Before adjusting control parameters for Assert, complete the following tasks:

Data Preparation
To adjust control parameters for Assert, you need the following data.

No. Data
1 Period for keeping the Assert state
5.9.2 Configuring the Period for Keeping the Assert State

The device that fails in the election prevents its downstream interface from forwarding multicast
data. After the holdtime of the Assert state expires, the downstream interface can forward
multicast data.
Context
NOTE

Procedure
1. Run:
system-view

2. Run:

3. Run:
holdtime assert interval
The period for holding the Assert state is set.
The switch that fails in the election prevents its downstream interface from forwarding
multicast data.
After the Holdtime of the Assert state expires, the downstream interface can forward
packets.
1. Run:
system-view

2. Run:


3. Run:
pim holdtime assert interval
The period for holding the Assert state is set.

The switch that fails in the election prevents its downstream interface from forwarding
multicast data.
After the Holdtime period of the Assert state expires, the downstream interface can
forward packets.
----End

After the control parameters for assert are adjusted, you can check information about the PIM
commands.
Procedure
interface.

----End



After basic functions of PIM-DM and IGMP are configured, you can configure the PIM silent
function on the interface connected with the user host. This interface should be enabled with
PIM-DM and IGMP first.
On the access layer, the interface directly connected to hosts needs to be enabled with PIM. You
can set up the PIM neighbor relationship on the interface to process various PIM packets. The
configuration, however, has the security vulnerability. When a host maliciously generates PIM
Hello messages and sends many packets to a switch, the switch may fail.
To prevent the preceding case, you can set the status of the interface to PIM silent. When the
interface is in the PIM silent state, the interface is prevented from receiving and forwarding any
PIM packet. All PIM neighbor relationships and PIM state machines on the interface are deleted.
At the same time, IGMP and MLD on the interface are not affected.
To enable PIM silent, the network environment must meet the following conditions:
l The network supports IPv4 and IPv6 simultaneously.

l PIM silent is applicable only to the interface directly connected to the host network segment
that is connected only to this switch.
CAUTION
If PIM silent is enabled on the interface connected to a switch, the PIM neighbor relationship
cannot be established and a multicast fault may occur.
If the host network segment is connected to multiple switchs and PIM silent is enabled on
multiple interfaces of the switchs, these interfaces do not send Assert messages. Therefore,
multiple interfaces that forward multicast data exist in the user network segment. A multicast
fault thus occurs.
Before configuring PIM silent, complete the following tasks:
l Configuring a unicast routing protocol to make the network reachable

l Configuring PIM-DM
l Configuring IGMP
Data Preparation
To configure PIM silent, you need the following data.

No. Data
1 Number of the interface connected to hosts
5.10.2 Configuring PIM Silent

After the interface is configured with PIM silent, it is forbidden to receive or forward any PIM
protocol packet. All PIM neighbors and PIM state machines on this interface are deleted. Then,
this interface automatically becomes the DR. IGMP on the interface is not affected.
Context
Do as follows on the interface connected to the host network segment:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Trunk interface.
Step 3 Run:
pim silent
PIM silent is enabled.

After PIM silent is enabled, the Hello message attack of malicious hosts is effectively prevented,
and the switch is protected.
----End

After PIM silent is configured, you can run the command to check information about the PIM
interface.
Prerequisite
All the configurations of PIM silent are complete.
Procedure
interface.
----End

Example
Run the display pim interface verbose command, and you can find that the configuration is
complete.
<Quidway> display pim interface Vlanif 10 verbose
Interface: Vlanif10,
PIM version: 2
PIM mode: Dense
PIM state: down
PIM DR: -
PIM neighbor count: -
PIM LAN delay (negotiated): -
PIM hello override interval (negotiated): -
PIM Silent: enabled
PIM neighbor tracking (negotiated): -
PIM generation ID: -
PIM require-GenID: disabled
PIM state-refresh processing: enabled
PIM state-refresh interval: 60 s
PIM graft retry interval: 3 s
PIM state-refresh capability on link: capable
PIM BFD: disabled
Number of routers on link not using DR priority: -
Number of routers on link not using LAN delay: -
Number of routers on link not using neighbor tracking: -
5.11 Maintaining PIM-DM (IPv4)

Maintaining PIM-DM involves resetting PIM statistics, and monitoring PIM running status.
5.11.1 Clearing Statistics of PIM Control Messages

If you need to re-collect the statistics about PIM control messages, you can reset the existent
statistics. Note that the statistics cannot be restored after you reset them. This operation does not
affect normal running of PIM.
Context
CAUTION
The statistics of the PIM control messages on the interface cannot be restored after you reset
them. Confirm the action before you run the command.

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
the statistics of the PIM control messages on an interface.
----End
5.11.2 Monitoring the Running Status of PIM

During the routine maintenance, you can run the display commands in any view to know the
running of PIM.
Context
In routine maintenance, you can run the following commands in any view to check the running
status of PIM.
Procedure
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] claimed-route
[ source-address ] command in any view to check the unicast routes used by PIM.
bsr } | interface interface-type interface-number ] * command in any view to check the
number of sent or received PIM control messages.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] grafts command
in any view to check unacknowledged PIM-DM Graft messages.
[ interface-type interface-number | up | down ] [ verbose ] command to check information
about PIM on an interface.
check information about a PIM neighbor.



----End
5.11.3 Debugging PIM

When a fault occurs during the running of PIM, run the debugging commands in the user view
and check the contents of sent and received packets for fault location.
Context
CAUTION
When a PIM fault occurs, run the following debugging command in the user view to debug PIM
and locate the fault.
For more information about debugging commands, refer to the Quidway S9300 Terabit Routing
Switch Debugging Reference.
Procedure
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] all command
in the user view to enable all the debugging of PIM.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] event
[ advanced-acl-number ] command in the user view to enable the debugging of PIM events.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] routing-
table [ advanced-acl-number ] command in the user view to enable the debugging of PIM
routes.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] neighbor
[ basic-acl-number | [ receive | send ] ] * command in the user view to enable the debugging
of PIM neighbors.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] assert
[ advanced-acl-number | [ receive | send ] ] * command in the user view to enable the
debugging of PIM Assert.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] join-prune
debugging of PIM Join/Prune.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] state-refresh
debugging of PIM State-Refresh.
----End


Configuration examples are provided to show how to construct a basic PIM-DM network.
5.12.1 Example for Configuring the PIM-DM Network
On the experiment network shown in Figure 5-2, multicast is deployed. The unicast routes work
normally. The Switches on the network need to be configured properly so that hosts can receive
the VOD information in multicast mode.
Figure 5-2 Networking diagram for configuring basic PIM-DM functions

SwitchA Ethernet
Receiver
GE2/0/0 HostA
Ethernet
GE1/0/0 N1
PIM-DM
Source GE3/0/0 Leaf network
GE4/0/0
GE1/0/0 GE2/0/0
SwitchD
N2
GE2/0/0 GE1/0/0 SwitchB
GE1/0/0 Receiver
HostB
GE2/0/0
Ethernet
SwitchC

GE 2/0/0 VLANIF 101 10.110.1.1/24
GE 2/0/0 VLANIF 102 10.110.2.1/24
GE 2/0/0 VLANIF 102 10.110.2.2/24
GE 2/0/0 VLANIF 300 192.168.3.2/24
GE 3/0/0 VLANIF 100 192.168.1.2/24
GE 4/0/0 VLANIF 103 10.110.5.1/24
In a small-scale experiment network, PIM-DM is adopted to configure multicast. Enable PIM
silent on the VLANIF interfaces of SwitchA to protect SwitchA from Hello message attacks.

1. Enable multicast on the Switch.

2. Enable PIM-DM on each interface.
3. Enable PIM silent and configure IGMP on the VLANIF interfaces connected to hosts.
Data Preparation
l Address of multicast group G: 225.1.1.1/24
l Address of multicast group S: 10.110.5.100/24
l Version of the IGMP protocol running between routers and hosts: IGMPv2
NOTE
This configuration example describes only the commands used to configure PIM-DM.
Procedure
Step 1 Enable multicast on all Switches and enable PIM-DM on all interfaces.
# Enable multicast on SwitchA and enable PIM-DM on each interface. The configurations of
SwitchB, SwitchC, and SwitchD are similar to the configuration of SwitchA, and are not
provided here.
[SwitchA-Vlanif100] pim dm
Step 2 Configure the interfaces connected to hosts to be PIM silent and configure IGMP on the interface.
# On SwitchA, configure the vlanif interfaces connected to hosts to be PIM silent, and configure
IGMP on the interface. The configurations of SwitchB, SwitchC, and SwitchD are similar to
configuration of SwitchA, and are not provided here.
[SwitchA-Vlanif101] pim silent

# Run the display pim interface command to view the configuration and operating of PIM on
the router interface. The display of the PIM configuration on SwitchD is as follows:
<SwitchD> display pim interface
Interface State NbrCnt HelloInt DR-Pri DR-Address
Vlanif103 up 0 30 1 10.110.5.1 (local)
Vlanif100 up 0 30 1 192.168.1.2 (local)
Vlanif200 up 0 30 1 192.168.2.2 (local)
Vlanif300 up 0 30 1 192.168.3.2 (local)
# Run the display pim neighbor command to check the PIM neighbor relationship between the
Switches. The display of the PIM neighbor relationship on SwitchD is as follows:
<SwitchD> display pim neighbor
Total Number of Neighbors = 3

Neighbor Interface Uptime Expires Dr-Priority BFD-

Session
192.168.1.1 Vlanif100 00:02:22 00:01:27 1
N
192.168.2.1 Vlanif200 00:00:22 00:01:29 1
N
192.168.3.1 Vlanif300 00:00:23 00:01:31 1 N
# Run the display pim routing-table command to view the PIM multicast routing table on the
Switch. Assume that HostA needs to receive the information about multicast group G
225.1.1.1/24. When sending multicast packets to multicast group G, multicast source S
10.110.5.100/24 generates an SPT through flooding and the (S, G) entries exist on SwitchA and
SwitchD that are in the SPT. When HostA joins multicast group G, an (*, G) entry is generated
on SwitchA. The information displayed on SwitchB and SwitchC is similar to the information
displayed on SwitchA. The displayed information is as follows:
<SwitchA> display pim routing-table
Total 1 (*, G) entry; 1 (S, G) entry
(*, 225.1.1.1)
Protocol: pim-dm, Flag: WC
UpTime: 03:54:19
Upstream interface: NULL
Upstream neighbor: NULL
RPF prime neighbor: NULL
1: Vlanif101
Protocol: igmp, UpTime: 01:38:19, Expires: never
(10.110.5.100, 225.1.1.1)
Protocol: pim-dm, Flag: ACT
UpTime: 00:00:44
1: Vlanif101
Protocol: pim-dm, UpTime: 00:00:44, Expires: never

(10.110.5.100, 225.1.1.1)
Protocol: pim-dm, Flag: LOC ACT
UpTime: 01:35:25
1: Vlanif100
2: Vlanif200
----End
Configuration Files

#
sysname SwitchA
#
#
vlan batch 100 101
#
interface Vlanif100
ip address 192.168.1.1 255.255.255.0
pim dm
#
interface Vlanif101
ip address 10.110.1.1 255.255.255.0
pim dm
pim silent
igmp enable
#
#
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 10.110.1.0 0.0.0.255
#
return
#
sysname SwitchB
#
#
vlan batch 200 102
#
interface Vlanif102
ip address 10.110.2.1 255.255.255.0
pim dm
igmp enable
#
interface Vlanif200
ip address 192.168.2.1 255.255.255.0
pim dm
#
#
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 10.110.2.0 0.0.0.255
#
return
#
sysname SwitchC
#
#

vlan batch 102 300

#
interface Vlanif102
ip address 10.110.2.2 255.255.255.0
pim dm
igmp enable
#
interface Vlanif300
ip address 192.168.3.1 255.255.255.0
pim dm
#
#
#
ospf 1
area 0.0.0.0
network 192.168.3.0 0.0.0.255
network 10.110.2.0 0.0.0.255
#
return
#
sysname SwitchD
#
#
vlan batch 100 103 200 300
#
interface Vlanif100
ip address 192.168.1.2 255.255.255.0
pim dm
#
interface Vlanif103
ip address 10.110.5.1 255.255.255.0
pim dm
#
interface Vlanif200
ip address 192.168.2.2 255.255.255.0
pim dm
#
interface Vlanif300
ip address 192.168.3.2 255.255.255.0
pim dm
#
#
#
#
#
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.1.0 0.0.0.255

network 10.110.5.0 0.0.0.255
#
return

Configuration Guide - Multicast 6 PIM-SM (IPv4) Configuration
6 PIM-SM (IPv4) Configuration
About This Chapter
The PIM protocol is used to implement multicast routing and data forwarding inside an AS. The
PIM-SM protocol is a multicast routing protocol of sparse node. It is applicable to a large-scale
network with sparsely-distributed members.
6.1 PIM-SM Overview
In a PIM-SM network, group members are sparsely distributed and almost all the network
segments do not have group members resided. Therefore, an RP is a forwarding core of the PIM-
SM network. All PIM devices in the PIM-SM network must know the location of the RP and
the RP collects information about both group members and multicast sources.
6.2 PIM-SM Features Supported by the S9300
The system can work normally with default PIM-SM parameters. You are also allowed to adjust
parameters related to neighbor discovery, forwarding, DR, RP, join, register, and assert. In
addition, you can configure various filtering policies and the PIM silent function to enhance the
PIM-SM security. PIM-SM supports SSM, PIM BFD, PIM GR, and SPT switchover.
6.3 Configuring Basic PIM-SM Functions
Ensure that unicast routes are reachable before configuring IPv4 multicast routing and enable
PIM-SM on each interface of the multicast device. In this manner, the PIM-SM network can
work normally.
6.4 Adjusting Control Parameters for a Multicast Source
6.5 Adjusting Control Parameters of the C-RP and C-BSR
If a dynamic RP is used, you can adjust parameters of C-RPs and C-BSR as required. If there is
no special requirement, default values are recommended.
6.6 Configuring a BSR Administrative Domain
A PIM-SM network can be divided into multiple BSR administrative domains and a global
domain. This effectively reduces the load of a single BSR, and provides a special service for
specific multicast groups.
6.7 Adjusting Control Parameters for Establishing the Neighbor Relationship

Multicast devices establish PIM neighbor relationships and negotiate various control parameters
by exchanging Hello messages. You can adjust the parameters carried in Hello messages as
required. If there is no special requirement, adopt default values.
6.8 Adjusting Control Parameters for Source Registering
In a PIM-SM network, the DR directly connected to the multicast source encapsulates multicast
data in a Register message and sends it to the RP in unicast mode. The RP then decapsulates the
message, and forwards the multicast data to receivers along the RPT. The system supports the
Register message filtering and suppression functions.
6.9 Adjusting Control Parameters for Forwarding
A multicast device sends Join messages upstream to require to forward multicast data and Prune
messages upstream for requiring to stop forwarding multicast data. You can adjust control
parameters for multicast data forwarding as required. If there is no special requirement, adopt
default values.
If a multicast device can receive multicast data through the downstream interface, this indicates
device.
6.11 Configuring the SPT Switchover
A high volume of multicast data traffic increases the load of an RP, and may result in a fault.
To solve this problem, PIM-SM allows the RP or the DR at the group member side to trigger
the SPT switchover when the rate of multicast packets is high.
6.12 Configuring PIM BFD
After detecting a fault on the peer, BFD immediately notifies the PIM module to trigger a new
DR election rather than waits until the neighbor relationship times out. This shortens the period
during which multicast data transmission is discontinued and thus improves the reliability of
multicast data transmission.
6.13 Configuring PIM GR
In a PIM-SM network, PIM GR can be applied to a device with dual main control boards to
ensure normal multicast data forwarding during master-slave switchover.
6.15 Maintaining PIM-SM (IPv4)
Maintaining PIM-SM involves resetting PIM statistics, and monitoring PIM running status.
Configuration examples are provided to show how to construct a basic PIM-SM network and
configure basic functions of PIM-SM.

6.1 PIM-SM Overview

In a PIM-SM network, group members are sparsely distributed and almost all the network
The Protocol Independent Multicast (PIM) indicates that any unicast routing protocol, such as
static route, RIP, OSPF, IS-IS, or BGP, can provide the routing information for IP multicast.
multicast routing is independent of unicast routing protocols, except that the unicast routing table
is used to generated multicast routing entries.
PIM forwards multicast packets by using the Reverse Path Forwarding (RPF) mechanism. The
RPF mechanism is used to create the multicast forwarding tree through the existing unicast
routing information. When a multicast packet arrives at a switch, the switch performs the RPF
check on the packet. If the RPF check succeeds, a multicast routing entry is created for
forwarding the multicast packet. If the RPF check fails, the packet is discarded.
NOTE
For details of RPF, refer to the chapter IPv4 Multicast Routing Management.
The working process of the Protocol Independent Multicast-Sparse Mode (PIM-SM) consists
of neighbor discovery, assert, DR election, RP discovery, join, prune, register, and SPT
switchover.
As shown in Figure 6-1, PIM-SM is used in a large-scale network with sparsely distributed
group members.
Figure 6-1 Application of PIM-SM a the multicast network

Receiver
UserA
IGMP
PIM-SM Receiver
PIM-SM IGMP
Source PIM-SM
UserB
PIM-SM PIM-SM
Multicast Receiver
Server PIM-SM IGMP
PIM-SM
UserC

NOTE
l The Protocol Independent Multicast Dense Mode (PIM-DM) is applicable to a small-scale network
with densely distributed members.
l PIM-SM can be used to construct the Any-Source Multicast (ASM) and Source-Specific Multicast
(SSM) models.

The system can work normally with default PIM-SM parameters. You are also allowed to adjust
parameters related to neighbor discovery, forwarding, DR, RP, join, register, and assert. In
addition, you can configure various filtering policies and the PIM silent function to enhance the
PIM-SM security. PIM-SM supports SSM, PIM BFD, PIM GR, and SPT switchover.
Basic PIM-SM Functions

PIM-SM supports the ASM and SSM models. You can set the range of ASM group addresses
or the range of SSM group addresses.
Static RP
You can specify a static RP on all the switchs in a PIM-SM domain. When a dynamic RP exists
in the domain, the dynamic RP is preferred by default, but you can configure the static RP to be
preferred.
Dynamic RP
You can configure C-RPs and C-BSRs in a PIM-SM domain and set the unified rules used to
dynamically generated the BSR and the RP. You can adjust the priority for C-RP election, adjust
the lifetime of the advertisement message on the BSR received from the C-RP, adjust the interval
for the C-RP to send advertisement messages, and specify an Access Control List (ACL) to limit
the range of the multicast groups served by the C-RP.
BSR
You can specify the C-BSR in the BSR domain, adjust the hash length used by the RP for C-RP
election, adjust the priority used for BSR election, and adjust the legal BSR address range. To
limit the transmission of BSR messages, you can configure the BSR service boundary on an
interface of the switch on the boundary of the BSR domain.
Filtering Policy Based on Source Addresses

You can configure filtering rules of the multicast source address to control multicast sources.
You can configure the policy to filter Register messages, and suppress PIM-SM Register
messages.
BSR Administrative Domain

You can configure the service boundary of the BSR administrative domain and the boundary of
the administrative domain by using the related commands.

Adjusting Parameters for Maintaining PIM-SM Neighbors

You can adjust the following parameters about PIM-SM neighbors, including:
l Interval for sending Hello messages
l Time period for the neighbor to hold the reachable state
l Whether to receive the Hello messages with Generation IDs
l Maximum delay in triggering the Hello messages
l Priority for DR election
l DR switching delay
addresses matching the filtering rules.
Configuring Control Parameters for Multicast Forwarding

You can adjust control parameters for multicast forwarding, including:
l Interval for sending Join messages
l Time period for the downstream interface to keep the forwarding state
l Time for overriding the prune action
l Filtering Join information in the Join/Prune messages
l Neighbor check function: checks whether the Join/Prune and Assert messages are sent to
or received from a PIM neighbor. If not, these messages are not processed.
Configuring Control Parameters for Assert

You can configure the period for retaining the Assert state of the switch interface.
Adjusting Control Parameters for SPT Switchover

You can adjust conditions of the SPT switchover and the interval for checking the forwarding
rate of multicast data.
PIM BFD
In the S9300, you can dynamically set up the BFD session to detect the status of the link between
PIM neighbors. Once a fault occurs on the link, BFD reports the fault to PIM.
PIM GR
The S9300 supports the PIM GR function on the switch with double MPUs. PIM GR ensures
normal multicast data forwarding during master-slave switchover of the switch.
Configuring PIM Silent

On the access layer, the switch interface directly connected to hosts needs to be enabled with
PIM. You can establish a PIM neighbor on the switch interface to process various PIM packets.
The configuration, however, has the security vulnerability. When a host maliciously generates
PIM Hello packets and sends the packets in large quantity, the switch may break down.
To prevent the preceding case, you can set the status of the switch interface to PIM silent. When
the interface is in the PIM silent state, the interface is prohibited from receiving and forwarding

any PIM packet. Then all PIM neighbors and PIM state machines on the interface are deleted.
The interface acts as the static DR and immediately takes effect. At the same time, IGMP on the
interface are not affected.
Multi-Instance PIM
In multi-instance applications, a multicast switch needs to maintain the PIM neighbor list,
multicast routing table, BSR information, and RP-Set information for different VPN instances
and keep the information independent between the instances. The switch functions as multiple
multicast switchs running PIM independently.
When a switch receives a data packet, it needs to differentiate which VPN instance the packet
belongs to and forward it based on the multicast routing table of that VPN instance, or create
PIM-related multicast routing entries in that VPN instance.
6.3 Configuring Basic PIM-SM Functions

PIM-SM on each interface of the multicast device. In this manner, the PIM-SM network can
work normally.

Before configuring basic PIM-SM functions, configure an IPv4 unicast routing protocol.
A PIM-SM network can adopt the ASM and SSM models to provide multicast services for user
hosts. The integrated components (including the RP) of the ASM model must be configured in
the network first. The SSM group address range is then adjusted as required.
NOTE
The SSM model is only supported in IGMPv3. If user hosts must run IGMPv1 or IGMPv2, configure IGMP
SSM mapping on switch interfaces.
Through IGMP, a switch knows the multicast group G that a user wants to join.
l If G is in the SSM group address range and the source S is specified when the user joins G
through IGMPv3, the SSM model is used to provide multicast services.
l If G is in the SSM group address range and the switch is configured with the (S, G) SSM
mapping rules, the SSM model is used to provide multicast services.
l If G is not in the SSM group address range, the ASM model is used to provide multicast
services.
In the PIM-SM network, the ASM model supports the following methods to obtain an RP. You
can select the method as required.
l Static RP: To obtain a static RP, manually configure RP on each switch in the PIM-SM
domain. For the large-scale PIM network, configuring the static RP is complicated. To
enhance the robustness and the operating management of the multicast network, the static
RP is usually used as the backup of the BSR-RP.

A multicast group may be in the service range of the dynamic RP and the static RP
simultaneously. By default, The switch prefers the dynamic RP. If the static RP precedence is
configured, the static RP is preferred.
Different multicast groups correspond to different RPs. Compared with all groups corresponding
to an RP, this can reduce the burden of an RP and enhance the robustness of the network.
Before configuring basic PIM-SM functions, complete the following tasks:
Data Preparation
To configure basic PIM-SM functions, you need the following data.
No. Data
1 Static RP address
2 ACL rule indicating the service scope of static RP
3 C-RP priority
4 ACL rule indicating the service scope of C-RP
5 Interval for C-RP sending Advertisement message
6 Timeout of the period during which BSR waits to receive the Advertisement message
from C-RP.
7 C-BSR Hash mask length
8 C-BSR priority
9 SSM group address range
6.3.2 Enabling IP Multicast Routing

Context
CAUTION
The configuration related to the VPN instance is applicable only to the PE switch. If the interface
of the VPN instance connects to the host, run the commands in step 3 and step 4.

Procedure
Step 1 Run:
system-view


optimize the multicast forwarding table before enabling IGMP snooping.
Step 3 Run:
IP multicast routing is enabled in the public network instance.


IP multicast routing is enabled is enabled in the VPN instance.

Before enable the multicast routing, the Route-distinguisher of the VPN instance must be
configured first.
----End
6.3.3 Enabling Basic PIM-SM Functions

An interface can set up PIM neighbor relationship with other devices after PIM-SM is enabled
on it.
Context
NOTE
PIM-SM and PIM-DM cannot be enabled on an interface at the same time. The PIM mode on all interfaces
that belong to the same instance must be consistent. When the switch is distributed in the PIM-SM domain,
enable PIM-SM on all non-boundary interfaces.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Trunk interface.
Step 3 Run:
pim sm
PIM SM is enabled.
After PIM SM is enabled on the interface and PIM neighbor relationships are set up between
switches, the packets from the PIM neighbors can be processed.
----End
6.3.4 (Optional) Configuring a Static RP

When only one RP exists in the network, you can manually configure a static RP rather than a
dynamic RP. This can save the bandwidth occupied by message exchange between the C-RP
and the BSR. The configurations about the static RP should be the same on all the devices in a
PIM-SM domain.
Context
CAUTION
When the static RP and the dynamic RP are configured in the PIM-SM at the same time, faults
may occur in the network. So, confirm the action before you run the command. If you want to
use only the dynamic RP in the PIM-SM network, skip the configuration.
Do as follows on all switchs in a PIM-SM domain. The switchs where static RP is not configured
cannot participate in multicast forwarding in this PIM-SM domain.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
static-rp rp-address [ basic-acl-number | acl-name acl-name ] [ preferred ]
The static RP is specified.
You can run the command repeatedly to configure multiple static RPs for the switch.
NOTE
All switchs in the PIM-SM area must be configured with the same static-rp command.
l rp-address: specifies the static RP address.

l basic-acl-number | acl-name acl-name: specifies the ACL. The ACL defines the range of
the multicast group served by the static RP. When the range of multicast groups that multiple
static RPs serve overlaps, the static RP with the largest IP address functions as the RP.
l preferred: indicates the preference of the static RP. If the C-RP is configured in the network
at the same time, the switch prefers the RP statically specified after preferred is used.
Otherwise, C-RP is preferred.
----End
6.3.5 (Optional) Configuring a Dynamic RP

In a PIM-SM domain, you can select several PIM devices and configure C-RPs on the devices.
Then, an RP is elected from these C-RPs. The C-BSRs should also be configured and a BSR is
elected from these C-BSRs. The BSR is responsible for collecting and advertising the C-RP
information on the network. The system supports the auto-RP listening function.
Context
CAUTION
The configuration is applicable only to the dynamic RP. If you want to use the static RP in the
network, skip the configuration.
Do as follows on the switch that may become RP in the PIM-SM area:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 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 ] *
The C-RP is configured.

l interface-type interface-number: specifies the interface where the C-RP resides. The
interface must be configured with PIM-SM.
l group-policy { basic-acl-number | acl-name acl-name }: specifies the multicast group
permitted by ACL and served by the C-RP. By default, C-RP serves all multicast groups.
l priority priority: specifies the priority for electing C-RP. The greater is the value, the lower
is the priority. By default, it is 0.
In the RP election, the C-RP with the highest priority wins. In case of the same priority, the
hash function is used and the C-RP with the greatest hash value wins. In case of the same
priority and the same hash value, the C-RP with the highest IP address wins.

NOTE
It is recommended to configure the loopback interfaces as RPs.

If the address borrowing is configured, it is not recommended to configure C-RP on the interfaces that
have the same addresses. If the priorities of the interfaces are different, the BSR considers that the C-
RP configuration is repeatedly modified.
l holdtime hold-interval: specifies the interval during which the BSR waits for the
Advertisement message from the C-RP. By default, the interval is 150 seconds.
l advertisement-interval adv-interval: specifies the interval during which the C-RP sends the
Advertisement message. By default, the interval is 60 seconds.
Step 4 Run:
c-bsr interface-type interface-number [ hash-length [ priority ] ]
The C-BSR is configured.

l interface-type interface-number: specifies the interface where the C-BSR resides. The
interface must be configured with the PIM-SM.
l hash-length: specifies the length of the hash. According to the G, C-RP address, and the value
of hash-length, switchs calculate the C-RPs that have the same priority and require to serve
G by operating hash functions, and compare the calculation results. The C-RP with the
greatest calculated value functions as the RP that serves G.
l priority: specifies the priority used by switchs to join the BSR election. The greater is the
value, the higher is the priority. By default, it is 0.
In the BSR election, the C-BSR with the highest priority wins. In the case of the same priority,
the C-BSR with the largest IP address wins.
bsm semantic fragmentation
The BSR message fragmentation is enabled.

It is recommended to enable BSR message fragmentation on all devices on the network because
BSR message fragmentation can solve the problem faced by IP fragmentation that all fragments
become unavailable due to loss of fragment information.
auto-rp listening enable
The Auto-RP listening is enabled.

When the switch interworks with a switch supporting auto-RP, this command needs to be
configured on the switch.
----End
6.3.6 (Optional) Configuring the SSM Group Address Range

The default SSM group address range is 232.0.0.0/8. You can manually configure the SSM group
address range. Ensure that the SSM group address ranges configured on all devices in the network
are identical.
Context
This configuration is optional. By default, the SSM group address range is 232.0.0.0/8.

Do as follows on all switchs in the PIM-SM domain:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ssm-policy { basic-acl-number | acl-name acl-name }
The SSM group address range is configured.

NOTE
Ensure that the SSM group address range of all switchs in the network is consistent.
----End

After basic functions of PIM-SM are configured, you can check information about the BSR, RP,
PIM interface, PIM neighbor, and PIM routing table through commands.
Procedure
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] bsr-info command
to check the BSR in a PIM-SM domain.
interface.
check a PIM neighbor.



l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] rp-info [ group-
address ] command to check the RP in a PIM-SM domain.
----End
6.4 Adjusting Control Parameters for a Multicast Source


After basic functions of PIM-SM are configured, you can configure the lifetime of a multicast
source and source address-based filtering rules as required.
All the configurations in this section are applicable to the ASM and SSM models.
PIM switchs check the multicast data that passes by. By checking whether the data matches the
filtering rule, the switchs determine whether to forward the data. That is, the switchs in the PIM
domain function as filters. The filters help to control the data flow, and to limit the information
that the downstream receiver can obtain.
Switchs can work normally under the control of default values. The S9300 allows users to adjust
the parameters as required.
NOTE
Before adjusting control parameters for a multicast source, complete the following tasks:
l Configuring a certain unicast routing protocol

l Configuring Basic PIM-SM Functions
Data Preparation
To adjust control parameters for a multicast source, you need the following data.
No. Data
1 Lifetime of a multicast source
2 Filtering rules based on multicast source addresses

6.4.2 Configuring the Lifetime of a Source

A multicast device starts a timer for each (S, G) entry. If the device does not receive any multicast
packets from a source within the lifetime of the source, it considers the corresponding (S, G)
entry as invalid and fails to receive multicast data for related groups.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
The lifetime of a source is configured.
If the lifetime of the source expires, the (S, G) entry becomes invalid.
----End

After ACL rules are configured, a multicast device can filter the received multicast packets based
on source addresses or source/group addresses.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
source-policy { acl-number | acl-name acl-name }
A filter is configured.

If the basic ACL is configured, only the packets with the source addresses that pass the filtering
are forwarded.
If the advanced ACL is configured, only the packets with the source addresses and group
NOTE
l If acl-number | acl-name acl-name is specified in the source-policy command, the multicast packets
with the specified source address or source and group addresses are forwarded.
l If acl-number | acl-name acl-name is specified in the source-policy command and no ACL rule is
l The source-policy command does not filter the static (S, G) entries and the PIM entries of the Join
messages received from private networks.
----End

Procedure

----End
6.5 Adjusting Control Parameters of the C-RP and C-BSR


If dynamic RP is used, after basic functions of PIM-SM are configured, you can adjust parameters
of the C-RP and C-BSR, configure a BSR boundary, and set valid address ranges for BSRs and
C-RPs.

This section describes how to adjust control parameters of the C-RP and the C-BSR by using
commands in the ASM model.
NOTE
The configuration is applicable only to a BSR-RP. If you want to use only a static RP in the network, skip
the configuration.
The switch can work properly by using default values of control parameters. The S9300 allows
users to adjust parameters.
NOTE
Default values are recommended.
Before adjusting control parameters of the C-RP and C-BSR, complete the following tasks:
Data Preparation
To adjust various control parameters of the C-RP and C-BSR, you need the following data.
No. Data
1 C-RP priority
2 Interval for a C-RP to send Advertisement messages
3 Timeout of the period during which a BSR waits to receive Advertisement messages
from a C-RP
4 Hash mask length of a C-BSR
5 Priority of a C-BSR
6 Interval for a C-BSR to send Bootstrap messages
7 Time of holding the Bootstrap message received from a BSR
8 ACL defining the valid BSR address scope
6.5.2 Adjusting C-RP Parameters

C-RPs periodically send Advertisement messages to a BSR. The Advertisement messages carry
C-RP priorities. You can adjust the C-RP priority, the interval for sending Advertisement
messages, and the holdtime of Advertisement messages on a device configured with the C-RP.
Context
Do as follows on the switch configured with the C-RP:

NOTE
You can re-set various parameters of a C-RP. This configuration is optional. If there is no specific
requirement, default values of parameters are recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
c-rp priority priority
The C-RP priority is set.

Step 4 Run:
c-rp advertisement-interval interval
The interval during which the C-RP sends Advertisement messages is set.
Step 5 Run:
c-rp holdtime interval
The time for holding the Advertisement message from a C-RP is set. The value must be greater
than the interval for a C-RP to send advertisement messages.
The C-RP periodically sends advertisement messages to the BSR. After receiving the
advertisement messages, the BSR obtains the Holdtime of the C-RP from the message. During
the Holdtime, the C-RP is valid. When the Holdtime expires, the C-RP ages out.
----End
6.5.3 Adjusting C-BSR Parameters

At first, each C-BSR considers itself as a BSR and sends Bootstrap messages to all devices in
the network. You can adjust the hash mask length of the C-BSR carried in a Bootstrap message,
the C-RP priority, the interval for sending Bootstrap messages, and the holdtime of Bootstrap
messages on a device configured with the C-BSR.
Context
Do as follows on the switch configured with the C-BSR:
NOTE
You can re-set various parameters of a C-BSR. This configuration is optional. If there is no specific
requirement, the default values of parameters are recommended.
Procedure
Step 1 Run:
system-view


Step 2 Run:

Step 3 Run:
c-bsr hash-length hash-length
The hash mask length of a C-BSR is set.

Step 4 Run:
c-bsr priority priority
The priority of the C-BSR is set.

Step 5 Run:
c-bsr interval interval
The interval for the BSR to send Bootstrap messages is set.

Step 6 Run:
c-bsr holdtime interval
The time of holding the Bootstrap message received from a BSR is set.
The BSR periodically sends a Bootstrap message to the network. After receiving the Bootstrap
message, the switchs keep the message for a certain time. During the period, the BSR election
stops temporarily. If the Holdtime timer times out, a new round of BSR election is triggered
among C-BSRs.
NOTE
Ensure that the value of c-bsr holdtime is greater than the value of c-bsr interval. Otherwise, the winner
of BSR election cannot be fixed.
----End
6.5.4 Configuring the BSR Boundary

A BSR boundary can be configured on an interface. Bootstrap messages cannot pass the BSR
boundary. Multiple BSR boundary interfaces divide the network into different PIM-SM
domains.
Context
Do as follows on the switch that may become the BSR boundary:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Trunk interface.
Step 3 Run:
pim bsr-boundary
The BSR boundary is configured. Bootstrap messages cannot pass the BSR boundary.
By default, all the PIM-SM switchs on the network can receive Bootstrap messages.
----End
6.5.5 (Optional) Configuring the BSR Address Range

ACL-based policies can be set on all devices to filter C-BSR addresses. The devices then receive
only the Bootstrap messages with the source addresses being in the valid C-BSR address range.
Thus, BSR spoofing is avoided.
Context
Do as follows on all switches in the PIM-SM domain:
NOTE
By default, all BSR packets are received without the BSR source address check.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
bsr-policy { basic-acl-number | acl-name acl-name }
The legal range of BSR addresses is set.
After receiving a BSR message, the switch checks the source address of the message. If the
source address is not within the range of legal addresses, the message is discarded. BSR spoofing
is thus prevented.
{ basic-acl-number | acl-name acl-name } specifies the basic ACL. The ACL defines the
filtering policy for the source address range of the BSR messages.
----End
6.5.6 (Optional) Configuring the Range of Valid C-RP Addresses

ACL-based policies can be set on all C-BSRs to filter C-RP addresses and addresses of the groups
that the C-RPs serve. The BSR adds C-RP information to the RP-set only when the addresses
are in the set legal address range. Thus, C-RP spoofing is avoided.

Context
Do as follows on all the C-BSRs in the PIM-SM domain:
NOTE
This configuration is optional. By default, a switch does not check the C-RP address and the group address
contained in a received Advertisement message and adds them to the RP-set.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
crp-policy { advanced-acl-number | acl-name acl-name }
The range of the valid C-RP addresses and the range of the multicast group addresses that a
switch serves are specified. When receiving an Advertisement message, the switch checks the
C-RP address and the addresses of the groups that the C-RP serves in the message. The C-RP
address and the addresses of the groups that the C-RP serves are added to the RP-Set only when
they are in the valid address range. The C-RP spoofing can thus be prevented.
{ advanced-acl-number | acl-name acl-name }: specifies the advanced ACL. The ACL defines
the filtering policy for the C-RP address range and the address range of the groups that a C-RP
serves.
----End

After the control parameters of C-RPs and C-BSRs are adjusted, you can check information
about the BSR and RP and check whether a BSR boundary is configured on the interface through
commands.
Procedure
----End
6.6 Configuring a BSR Administrative Domain

A PIM-SM network can be divided into multiple BSR administrative domains and a global
domain. This effectively reduces the load of a single BSR, and provides a special service for
specific multicast groups.


After dynamic RP and basic PIM-SM functions are configured, you can configure BSR
administrative domains as required. Each BSR administrative domain maintains a BSR and
provides services for the multicast groups within a specific address range. Multicast groups that
do not belong to any BSR administrative domain are served by the global domain.
This section describes how to configure a BSR administrative domain in the ASM model through
commands.
In the traditional mode, a PIM-SM network maintains only one BSR and all multicast groups in
the network are in the administrative range of the BSR. To better manage the domains, the PIM-
SM network is divided into multiple BSR administrative domains. Each BSR administrative
domain maintains only one BSR that serves specified multicast groups. BSR administrative
domains are geographically isolated. Multicast packets of a BSR administrative domain cannot
pass the border of the domain.
The address of a multicast group served by a BSR administrative domain is valid only in the
BSR administrative domain. The addresses of multicast groups served by different BSR
administrative domains can be identical and these addresses are equal to private multicast group
addresses.
Multicast groups that do not belong to any BSR administrative domain are served by the global
domain. Global domain maintains only one BSR that serves the remaining multicast groups.
Dividing a PIM-SM network into multiple BSR administrative domains and a global domain
effectively reduces the load of a single BSR, and provides a special service for specific multicast
groups.
The switch can work normally under the control of default values. The S9300 allows users to
adjust the parameters.
NOTE
Default values are recommended.
Before configuring a BSR administrative domain, complete the following tasks:

Data Preparation
To configure a BSR administrative domain, you need the following data.
No. Data
1 Priority and hash mask length for electing a BSR in a BSR domain
2 Priority and hash mask length of electing the global domain BSR

6.6.2 Enabling a BSR Administrative Domain

Enable BSR administrative domains on all devices in a PIM-SM network.
Context
Do as follows on all switchs in the PIM-SM network:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
c-bsr admin-scope
The division of BSR administrative domains is enabled in a PIM-SM network.
----End
6.6.3 Configuring the Boundary of a BSR Administrative Domain

After an interface is configured as a BSR administrative domain boundary, all the multicast
packets for the groups in this BSR administrative domain cannot pass this interface.
Context
Do as follows on all switchs at the boundary of a BSR administrative domain:
NOTE
The switchs outside the BSR administrative domain cannot forward the multicast packets of the BSR
administrative domain.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Trunk interface.
Step 3 Run:
multicast boundary group-address { mask | mask-length }

The BSR administrative domain boundary is configured. Multicast packets that belong to the
BSR administrative domain cannot traverse the boundary.
----End
6.6.4 Adjusting C-BSR Parameters

You can adjust the C-BSR parameters of the BSR administrative domain and the global domain
as required.
Context
Do as follows on all C-BSRs:
NOTE
The C-BSR configuration involves three cases:

l Global configuration: For global configuration, see Adjusting Control Parameters of the C-RP and
C-BSR. It is valid in the global domain and each BSR administrative domain.
l Configuration in a BSR administrative domain: Because the configuration in a BSR administrative
domain takes precedence over the global configuration, the global configuration is used when the
configuration in a BSR administrative domain is not done.
l Configuration in the global domain: Because the configuration in the global domain takes precedence
over the global configuration, the global configuration is used when the configuration in the global
domain is not done.
Procedure
l Configuration in a BSR Administrative Domain
1. Run:
system-view

2. Run:

3. Run:
c-bsr group group-address { mask | mask-length } [ hash-length hash-
length | priority priority ] *
The C-BSR parameters are configured.
– group-address { mask | mask-length }: specifies the range of the multicast groups

served by a C-BSR. Group addresses in the 239.0.0.0/8 are valid group addresses.
– hash-length hash-length: specifies the hash mask length of a C-BSR.
– priority priority: specifies the priority of a C-BSR.
l Configuration in the Global Domain
1. Run:
system-view

2. Run:


3. Run:
c-bsr global [ hash-length hash-length | priority priority ] *
The C-BSR parameters are configured.
– hash-length hash-length: specifies the hash mask length of a C-BSR.

– priority priority: specifies the priority of a C-BSR.
----End

After a BSR administrative domain is configured, you can run commands to view configurations
about the BSR and RP.
Procedure
----End
6.7 Adjusting Control Parameters for Establishing the

Neighbor Relationship

After basic functions of PIM-SM are configured, you can adjust related parameters of Hello
messages for controlling neighbor relationships, and configure the downstream neighbor
tracking function and the neighbor filtering function.
The configuration in this section is applicable to both the ASM model and the SSM model.
The PIM switchs send Hello messages to each other to establish the neighbor relationship,
negotiate the control parameters, and elect a DR.
The switch can work normally by default. The S9300 allows the users to adjust the parameters
as required.
NOTE
It is recommended to adopt the default value if there is no special requirement.

Before configuring control parameters for establishing the neighbor relationship, complete the
following tasks:
l Configuring unicast routing protocol
Data Preparation
To adjust the control parameters for establishing the neighbor relationship, you need the
following data.
No. Data
1 Priority of the DR that is elected
2 Timeout period for waiting for Hello messages from a neighbor
5 DR switchover delay, that is, the period during which the original entries are still
valid when the interface changes from a DR to a non-DR.
6.7.2 Configuring Control Parameters for Establishing the

Neighbor Relationship
Context
Do as follows on the PIM-SM switch.
NOTE

l Global configuration: It is valid on all the interfaces.
Procedure
1. Run:
system-view

2. Run:

3. Run:

4. Run:
The timeout period of holding the reachable state of a neighbor is set.
If no Hello message is received after the interval expires, the neighbor is considered
unreachable.
1. Run:
system-view

2. Run:

3. Run:
pim timer hello interval

4. Run:
pim triggered-hello-delay interval
This can prevent the conflict of Hello messages sent by multiple PIM switchs at the
same time.
5. Run:
pim hello-option holdtime interval
The timeout period of holding the reachable state of a neighbor is set.
If no Hello message is received after the interval expires, the neighbor is considered
unreachable.
6. Run:
pim require-genid
The Generation ID option is contained in a received Hello message. The Hello message
without the Generation ID option is rejected.
By default, the switch handles the Hello message without the Generation option.
----End

6.7.3 Configuring Control Parameters for Electing a DR

The control parameters for electing a DR can be set either globally or on an interface.
Context
Do as follows on the PIM-SM switch:
NOTE

Procedure
1. Run:
system-view

2. Run:

3. Run:
hello-option dr-priority priority
The DR priority is set.

On a shared network segment where all PIM switchs support the DR priority, the
interface with the highest priority acts as the DR. In the case of the same priority, the
interface with the largest IP address acts as the DR. If a minimum of one PIM
switch does not support the DR priority, the interface with the largest IP address acts
as the DR.
1. Run:
system-view

2. Run:

3. Run:
pim hello-option dr-priority priority
The DR priority is set.

On a shared network segment where all PIM switchs support the DR priority, the
interface with the highest priority acts as the DR. In the case of the same priority, the

interface with the largest IP address acts as the DR. If a minimum of one PIM
switch does not support the DR priority, the interface with the largest IP address acts
as the DR.
----End
6.7.4 Enabling the Function of Tracking a Downstream Neighbor

Context
NOTE

l Configuration on the interface: The configuration on an interface takes precedence over the global
Procedure
l Global configuration
1. Run:
system-view

2. Run:

3. Run:
hello-option neighbor-tracking
The function of tracking a downstream neighbor is enabled.

After this function is enabled, information about the downstream neighbor who has
sent a Join message and whose Join state does not times out is recorded.
NOTE
The function of tracking downstream neighbors cannot be implemented unless all the PIM
switchs in the shared network segment are enabled with this function.
l Configuration on an interface
1. Run:
system-view

2. Run:


3. Run:
pim hello-option neighbor-tracking
The function of tracking a downstream neighbor is enabled.

NOTE
The function of tracking downstream neighbors cannot be implemented unless all PIM
switchs in the shared network segment are enabled with this function.
----End

Context
To prevent some switch from being involved in the PIM protocol and prevent the switch from
becoming the DR, filtering PIM neighbors is required.
Do as follows on the switch enabled with PIM-SM:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Trunk interface.
Step 3 Run:
pim neighbor-policy { basic-acl-number | acl-name acl-name }

NOTE
----End


Procedure
interface.
check a PIM neighbor.
----End
6.8 Adjusting Control Parameters for Source Registering

data in a Register message and sends it to the RP in unicast mode. The RP then decapsulates the
message, and forwards the multicast data to receivers along the RPT. The system supports the
Register message filtering and suppression functions.

After basic functions of PIM-SM are configured, you can configure filtering policies and the
checksum method for Register messages and configure PIM-SM Register suppression as
required.
This section describes how to configure the control parameters of the source registering through
commands.
In a PIM-SM network, the DR directly connected to the source S encapsulates multicast data in
a Register message and sends it to the RP in unicast mode. The RP then decapsulates the message,
and forwards it along the RPT.
After the SPT switchover on the RP is complete, the multicast data reaches the RP along the
SPT tree in the multicast mode. The RP sends a Register-stop message to the DR at the source
side. The SDR stops sending Register messages and enters the suppressed state. During the
register suppression, the SDR periodically sends null-register packets to inform that the source
is still in the active state. After the timeout of the register suppression, the SDR starts to send
Register message again.
The switch can work normally under the control of default values. The S9300 allows the users
to adjust the parameters as required.
NOTE
It is recommended to adopt default values if there is no special requirement.
Before adjusting control parameters for source registering, complete the following tasks:


Data Preparation
To adjust control parameters for source registering, you need the following data.
No. Data
1 ACL rules used by the RP to filter Register messages
2 Whether the checksum is calculated only according to the header of a Register

message
3 Timeout for keeping the suppressed state of registering
4 Interval for sending null Register messages to the RP
6.8.2 Configuring PIM-SM Register Messages

You can configure filtering policies for Register messages on all the devices that may become
RPs. By default, the checksum is calculated based on the entire Register message. You can
configure the device to calculate the checksum based on only the header of a Register message.
Context
Do as follows on all switchs that may become an RP:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
register-policy { advanced-acl-number | acl-name acl-name }
The policy for filtering Register messages is set.

The RP applies the policy to filter received Register messages.
Step 4 Run:
register-header-checksum
The checksum is calculated only according to the header of a Register message.

By default, the checksum is calculated according to the entire message.
----End

6.8.3 Configuring PIM-SM Register Suppression

You can set the timeout period for keeping the register suppression state and the interval for
sending null Register messages on all the devices that may becomes DRs at the multicast source
side.
Context
Do as follows on all the switchs that may become the DR at the multicast source side:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
register-suppression-timeout interval
The timeout for keeping the suppressed state of registering is set.
Step 4 Run:
probe-interval interval
The interval for sending null Register messages is set.
----End

After control parameters for source registering are adjusted, you can run the corresponding
command to check information about the PIM interface.
Procedure
interface.
----End

A multicast device sends Join messages upstream to require to forward multicast data and Prune
messages upstream for requiring to stop forwarding multicast data. You can adjust control
parameters for multicast data forwarding as required. If there is no special requirement, adopt
default values.


After basic functions of PIM-SM are configured, you can adjust related control parameters of
forwarding relationship maintenance, and configure the Join information filtering and neighbor
filtering functions to enhance security as required.
The configurations in this section are applicable to the ASM model and the SSM model.
When the first member of a group appears in the network segment, the switch sends a Join
message through an upstream interface, requiring the upstream switch to forward packets to the
network segment.
When the last member of the group leaves, the switch sends a Prune message through an upstream
interface, requiring the upstream switch to perform the Prune action and to stop forwarding
packets to this network segment. If other downstream switchs in this network segment still want
to receive data of this group, they must send a Join message to override the Prune action.
In the ASM model, a switch periodically sends Join messages to the RP to prevent RPT branches
from being deleted due to timeout.
adjust the parameters as required.
NOTE
Before adjusting control parameters for forwarding, complete the following tasks:

Data Preparation
To adjust control parameters for forwarding, you need the following data.
No. Data
2 Period of overriding the Prune action
4 Interval for sending Join messages
5 Number or name of the ACL used to filter join information in the Join/Prune messages
6 Whether neighbor check needs to be performed after Join/Prune message and Assert
messages are sent or received

6.9.2 Configuring Control Parameters for Keeping the Forwarding

State
The control parameters of multicast data forwarding can be set either globally or on an interface.
The parameters specify the interval for sending Join/Prune messages and the period for a
downstream interface to keep the Join/Prune state.
Context
NOTE

Procedure
1. Run:
system-view

2. Run:

3. Run:
timer join-prune interval
The interval for sending Join/Prune messages is set.

4. Run:
The interval for holding the forwarding state of a downstream interface is set.
1. Run:
system-view

2. Run:

3. Run:
pim timer join-prune interval

4. Run:
pim holdtime join-prune interval
The interval for holding the forwarding state of a downstream interface is set.
5. Run:
pim require-genid
The Generation ID option is contained in a received Hello message. The Hello message
without the Generation ID option is rejected.
By default, the switch handles the Hello message without the Generation option.
The change of the Generation ID in the Hello message received from an upstream
neighbor indicates that the upstream neighbor is lost or the status of the upstream
neighbor has changed. The switch immediately sends the Join/Prune message to the
upstream switch to refresh the status.
----End
6.9.3 Configuring Control Parameters for Prune

The control parameters for prune can be set either globally or on an interface. The parameters
specify the delay for transmitting messages in a LAN and the interval for overriding the Prune
action.
Context
NOTE

l Global Configuration: It is valid on all the interfaces.
Procedure
1. Run:
system-view

2. Run:

3. Run:

A Hello message carries lan-delay and override-interval . PPT indicates the delay
from the time when a switch receives the Prune message from a downstream interface
to the time when the switch performs the prune action to suppress the forwarding of
the downstream interface. The PPT is obtained by the lan-delay plus override-interval.

If the switch receives a Join message from a downstream switch within the PPT, the
switch does not perform the prune action.
4. Run:
The interval for overriding the Prune action is set.
If a switch receives the Prune message through an upstream interface, this indicates
that other downstream switchs exist in this LAN. If the switch still needs to receive
multicast data of the group, the switch must send a Join message to the upstream
switch within the override-interval.
1. Run:
system-view

2. Run:

3. Run:
pim hello-option lan-delay interval

4. Run:
pim hello-option override-interval interval
The interval for overriding the Prune action is set.
----End
6.9.4 Configuring Join Information Filtering

A Join/Prune message received by an interface may contain both join information and prune
information. You can configure the interface to filter join information based on ACL rules. The
device then creates PIM entries for only the join information matching ACL rules.
Context
information. You can configure the switch to filter join information based on ACL rules. The
switch then creates PIM entries for only the join information matching ACL rules, which can
avoid access of illegal users.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Trunk interface.
Step 3 Run:
pim join-policy { asm { basic-acl-number | acl-name acl-name } | ssm { advanced-acl-
number | acl-name acl-name } }
Join information filtering is configured.
----End
6.9.5 Configuring Neighbor Check

If PIM neighbor check is enabled, a device checks whether the Join/Prune and Assert messages
are sent to or received from PIM neighbors. If not, the device drops the messages.
Context
By default, checking whether the Join/Prune message and Assert messages are sent to or received
from a PIM neighbor is not enabled.
If PIM neighbor checking is required, it is recommended to configure the neighbor checking

function on the devices connected with user devices rather than on the internal devices of the
network. Then, the switch checks whether the Join/Prune and Assert messages are sent to or
received from a PIM neighbor. If not, the switch drops the messages.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
neighbor-check { receive | send }
The neighbor check function is configured.
You can specify both receive and send to enable the PIM neighbor check function for the
received and sent Join/Prune and Assert messages.
----End


After control parameters for multicast data forwarding are adjusted, you can check information
about the PIM interface and the PIM routing table and statistics about PIM control messages
through commands.
Procedure
interface.

----End

device.

After basic functions of PIM-SM are configured, you can set the period for holding the Assert
state as required.
The configurations in this section ares applicable to the ASM model and the SSM model.

If a PIM-SM switch receives multicast data through a downstream interface, it indicates that
other upstream switchs exist in this network segment. switchs send Assert messages to elect the
unique upstream switch.
adjust the parameters as required.
NOTE
Before adjusting control parameters for assert, complete the following tasks:

Data Preparation
To adjust control parameters for assert, you need the following data.
No. Data
1 Interval for holding the Assert state

data during the Assert state. After the holdtime of the Assert state expires, the downstream
interface can forward multicast data.
Context
Do as follows on all the switchs in the PIM-SM domain:
NOTE

Procedure
1. Run:
system-view

2. Run:


3. Run:
The interval for holding the Assert state is set.
The switch that fails in the election prevents the downstream interface from forwarding
multicast packets within the interval. After the interval expires, the downstream
interface starts to forward multicast packets.
l Configuration on the Interface
1. Run:
system-view

2. Run:

3. Run:
pim holdtime assert interval
The interval for holding the Assert state is configured.
The switch that fails in the election prohibits the downstream interface from
forwarding multicast packets within this interval. After the interval expires, the
downstream interface starts to forward multicast packets.
----End

commands.
Procedure
interface.



----End
6.11 Configuring the SPT Switchover

To solve this problem, PIM-SM allows the RP or the DR at the group member side to trigger
the SPT switchover when the rate of multicast packets is high.

After basic functions of PIM-SM are configured, you can adjust control parameters for SPT
switchover as required.
This section describes how to configure the control parameters of the SPT switchover through
commands.
In a PIM-SM network, each multicast group corresponds to an RPT. At first, all multicast sources
encapsulate data in Register messages, and send them to the RP in the unicast mode. The RP
decapsulates the messages and forwards them along the RPT.
Forwarding multicast data by using the RPT has the following defects:
l The DR at the source side and the RP need to encapsulate and decapsulate packets.
l Forwarding path may not be the shortest path from the source to receivers.
l Large-volume data flow increases the load of the RP, and may cause a fault.
The solution to the preceding defects is that:
l SPT switchover triggered by the RP: The RP sends a Join message to the source, and
establishes a multicast route along the shortest path from the source to the RP. The
subsequent packets are forwarded along the path.
l SPT switchover triggered by the DR at the member side: The DR at the member side checks
the forwarding rate of multicast data. If the DR finds that the rate exceeds the threshold,
the DR tiggers the SPT switchover immediately. The DR sends a Join message to the source,
and establishes a multicast route along the shortest path from the source to the DR. The
subsequent packets are forwarded along the path.

Switchs can work normally under the control of default values. The S9300 allows users to adjust
the parameters as required.
NOTE
Before configuring the SPT switchover, complete the following tasks:
Data Preparation
To configure the SPT switchover, you need the following data.
No. Data
1 Rate threshold that a leaf PIM switch switches packets from the RPT to the SPT
2 Group filtering policy and sequence policy for the switchover from the RPT to the
SPT
3 Interval for checking the rate threshold of multicast data before the RPT-to-SPT
switchover
6.11.2 (Optional) Configuring the Interval for Checking the

Forwarding Rate of Multicast Data
You can configure conditions for the SPT switchover and set the interval for checking the
forwarding rate of multicast data on the DR at the group member side.
Context
Do as follows on all the switchs that may become a DR at the member side:
Procedure
Step 1 Run:
system-view

Step 2 Run:

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 set.

l traffic-rate: specifies the rate threshold of the SPT switchover.

l infinity: indicates that the SPT switchover is not triggered forever.
l group-policy { basic-acl-number | acl-name acl-name } [ order order-value]: specifies the
range of the multicast groups that use the threshold. By default, the threshold is applicable
to all multicast groups.
Step 4 Run:
timer spt-switch interval
The interval for checking the forwarding rate of multicast data is set.
----End

After the control parameters for SPT switchover are adjusted, you can run commands to check
Procedure

----End
6.12 Configuring PIM BFD

After detecting a fault on the peer, BFD immediately notifies the PIM module to trigger a new
DR election rather than waits until the neighbor relationship times out. This shortens the period
during which multicast data transmission is discontinued and thus improves the reliability of
multicast data transmission.

After basic functions of PIM-SM are configured, you can configure PIM BFD to improve PIM
network reliability, and adjust BFD parameters as required.

Generally, if the current DR in a shared network segment is faulty, other PIM neighbors triggers
a new round of DR election only after the neighbor relationship times out. The duration that data
transmission is interrupted is not shorter than the timeout period of the neighbor relationship.
Generally, it is of second level.
BFD features fast detection of faults, and is up to the millisecond level. BFD can detect statuses
of PIM neighbors in the shared network segment. When BFD detects that a peer is faulty, BFD
immediately reports it to PIM. PIM then triggers a new round of DR election without waiting
for the timeout of the neighbor relationship. This shortens the duration of interruption of data
transmission and enhances the reliability of the network.
PIM BFD is also applicable to the assert election in a shared network segment. It can fast respond
to the fault of the interface that wins the assert election.
Before configuring PIM BFD, complete the following task:
l Enabling BFD in the system view
Data Preparation
To configure PIM BFD, you need the following data.
No. Data
1 Minimum intervals for sending and receiving BFD detection messages, and local
detection multiple
6.12.2 Configuring PIM BFD

Enable PIM BFD on the devices that set up a PIM neighbor relationship.
Context
NOTE
This function is applicable to NBMA interfaces and broadcast interfaces rather than MTunnel interfaces.
Do as follows on PIM switchs that set up the neighbor relationship:
Procedure
Step 1 Run:
system-view

Step 2 Run:

The interface must be a VLANIF interface.
Step 3 Run:
pim bfd enable
PIM BFD is enabled.
By default, PIM BFD is disabled.
----End
6.12.3 (Optional) Adjusting BFD Parameters

You can adjust PIM BFD parameters as required. PIM BFD parameters include the minimum
interval for sending and receiving PIM BFD packets and the local detection multiplier.
Context
Do as follows on two PIM switchs that set up the neighbor relationship:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The interface view is displayed
The interface must be a VLANIF interface.
Step 3 Run:
pim bfd { min-tx-interval tx-value | min-rx-interval rx-value | detect-multiplier
multiplier-value }*
PIM BFD parameters are adjusted.
PIM BFD parameters include the minimum interval for sending PIM BFD messages, the
minimum interval for receiving PIM BFD messages, and the local detection multiple.
If this command is not used, the default values of these parameters are used. When the BFD
parameters configured for other protocols are the same as those configured for PIM, the
configurations of the PIM BFD parameters are affected.
----End

After PIM BFD is configured, you can run the command to check information about PIM BFD
sessions.

Procedure
l Run the following commands to check information about a PIM BFD session.
– display pim [ vpn-instance vpn-instance-name | all-instance ] bfd session statistics
– display pim [ vpn-instance vpn-instance-name | all-instance ] bfd session
[ interface interface-type interface-number | neighbor neighbor-address ] *
----End
6.13 Configuring PIM GR

In a PIM-SM network, PIM GR can be applied to a device with dual main control boards to
ensure normal multicast data forwarding during master-slave switchover.

After basic functions of PIM-SM are configured, you can configure PIM GR to improve PIM
network reliability.
In some multicast applications, the switch may need to perform active/standby switchover. After
active/standby switchover, the new active main control board deletes the forwarding entries on
the interface board and re-learns the PIM routing table and multicast routing table. During this
process, multicast traffic is interrupted.
In the PIM-SM/SSM network, PIM Graceful Restart (GR) can be applied to the switch with dual
main control boards to ensure normal multicast traffic forwarding during active/standby
switchover.
The active main control board of the switch backs up PIM routing entries and Join/Prune
information to be sent upstream to the standby main control board. The interface board maintains
forwarding entries. Therefore, after active/standby switchover, the switch can actively and fast
send Join messages upstream to maintain the Join state of the upstream. In addition, the PIM
protocol sends Hello message carrying new Generation ID to all switchs enabled with PIM-SM.
When the downstream switch finds that the Generation ID of its neighbor changes, it sends a
Join/Prune message to the neighbor for re-creating routing entires, thereby ensuring non-stop
forwarding of multicast data on the forwarding plane.
If a dynamic RP is used on the network, after receiving a Hello message with the Generation ID
being changed, the DR or candidate DR unicasts a BSM message to the switch performing active/
standby switchover and the switch learns and restores RP information based on the received
BSM message. If the switch has not leant any RP information from the BSM messages, it obtains
the RP information from the Join/Prune message received from the downstream router and re-
creates multicast routing table.
NOTE
PIM GR is applicable to PIM-SM/SSM networks.
Before enabling PIM GR, complete the following task:

l Configuring a unicast routing protocol and enabling unicast GR

Data Preparation
To enable PIM GR, you need the following data.
No. Data
1 Unicast GR period
2 PIM GR period
6.13.2 Configuring PIM GR

After PIM GR is enabled on a device, you can set the PIM GR period as required.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
graceful-restart
PIM GR is enabled.

graceful-restart period period
The PIM GR period is set.
By default, the PIM GR period is 120 seconds.
----End

After PIM GR is configured, you can run the command to check whether the PIM routing table
is the same as that before master-slave switchover.

Procedure
Step 1 Run the following commands to check PIM routing table.
l display pim { vpn-instance vpn-instance-name | all-instance } routing-table [ group-
mask-length | source-mask } ] | incoming-interface { interface-type interface-number |
register } | outgoing-interface { include | exclude | match } { interface-type interface-
number | register | none } | mode { dm | sm | ssm } | flags flag-value | fsm ] * [ outgoing-
interface-number [ number ] ]
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 | vpn-instance vpn-instance-name | register |
none } | mode { dm | sm | ssm } | flags flag-value | fsm ] * [ outgoing-interface-number
[ number ] ]
l display pim [ vpn-instance vpn-instance-name | all-instance ] routing-table brief [ group-
mask-length | source-mask } ] | incoming-interface { interface-type interface-number |
register } ] *
----End


After basic functions of PIM-SM and IGMP are configured, you can configure the PIM silent
function on the interface connected with the user host. This interface should be enabled with
PIM-SM and IGMP first.
On the access layer, the interface directly connected to hosts needs to be enabled with PIM. You
can establish the PIM neighbor relationship on the interface to process various PIM packets. The
configuration, however, has potential risks of security. When a host maliciously generates PIM
Hello packets and sends the packets in large quantity, the switch may fail.
To solve the problem, set the status of the interface to PIM silent. When the interface is in PIM
silent state, the interface is prevented from receiving and forwarding any PIM packet. All PIM
neighbors and PIM state machines on the interface are deleted. The interface acts as the static
DR and immediately takes effect. At the same time, IGMP and MLD on the interface are not
affected.
PIM silent is applicable only to the interface directly connected to the host network segment that
is connected only to this switch.

CAUTION
If PIM silent is enabled on the interface connected to a switch, the PIM neighbor relationship
cannot be set up and a multicast fault may occur.
If the host network segment is connected to multiple switchs and PIM silent is enabled on
multiple interfaces, the interfaces become static DRs. Therefore, multiple DRs exist in this
network segment, and a fault occurs.
Before configuring PIM silent, complete the following tasks:
l Configuring a unicast routing protocol to make the network layer reachable
l Configuring PIM-SM
l Configuring IGMP
Data Preparation
To configure PIM silent, you need the following data.
No. Data
1 The number of the interface connected to hosts
6.14.2 Configuring PIM Silent

Context
Do as follows on the interface connected to the host network segment:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Trunk interface.
Step 3 Run:

pim silent
PIM silent is enabled.
After PIM silent is enabled, the Hello packet attack of malicious hosts is effectively prevented
and the switch is protected.
----End

interface.
Prerequisite
Procedure
interface.
----End
Example
Run the display pim interface verbose command, and you can find that the configuration is
complete.
<SwitchA> display pim interface verbose
Interface: Vlanif10, 2.2.2.2
PIM version: 2
PIM mode: Sparse
PIM DR: 2.2.2.2 (local)
PIM neighbor count: 0
PIM LAN delay (negotiated): 500 ms
PIM hello override interval (negotiated): 2500 ms
PIM Silent: enabled
PIM neighbor tracking (negotiated): disabled
PIM generation ID: 0X2649E5DA
PIM require-genid: disabled
PIM BSR domain border: disabled
PIM BFD: disabled
Number of routers on link not using DR priority: 0
Number of routers on link not using LAN delay: 0
Number of routers on link not using neighbor tracking: 1

6.15 Maintaining PIM-SM (IPv4)

Maintaining PIM-SM involves resetting PIM statistics, and monitoring PIM running status.

If you need to re-collect the statistics about PIM control messages, you can reset the existent
Context
CAUTION
The statistics of PIM control messages on an interface cannot be restored after you clear it. So,
confirm the action before you use the command.
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
the statistics of PIM control messages on an interface.
----End
6.15.2 Clearing the PIM Status of the Specified Downstream

Interfaces of PIM Entries
You can clear the PIM Join/Prune state and Assert state on the specified downstream interface
of a PIM entry. IGMP status and static multicast groups on this interface are not affected.
Context
CAUTION
Clearing PIM status of the downstream interfaces may trigger the sending of corresponding Join/
Prune messages, which affects multicast services.
Using the following command can clear join information about illegal users, and clear the PIM
status of the specified interface in a specified entry, such as PIM Join/Prune status and Assert
status.
The command cannot be used to clear the IGMP or static group join status on a specified
interface.

Procedure
Step 1 After confirming that PIM status of the specified downstream interfaces of the specified PIM
entry need to be cleared, 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.
----End
6.15.3 Monitoring the Running Status of PIM-SM

running of PIM.
Context
status of PIM-SM.
Procedure
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] claimed-route
[ source-address ] command in any view to check the 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 in
any view to check information about a PIM BFD session.
in any view to check information about the BSR in a PIM-SM domain.
bsr } | interface interface-type interface-number ] * command in any view to check the
number of sent or received PIM control messages.
[ interface-type interface-number | up | down ] [ verbose ] command in any view to check
PIM on an interface.
neighbor [ neighbor-address | interface interface-type interface-number | verbose ] * to
check PIM neighbors.
l Run the following commands in any view to check the PIM routing table.



address ] command in any view to check information about the RP to which a multicast
group corresponds.
----End
6.15.4 Debugging PIM

When a fault occurs during the running of PIM, run the debugging commands in the user view
Context
CAUTION
Debugging affects the performance of the system. So, after debugging, execute the undo
debugging all command to disable it immediately.
When a PIM fault occurs, run the following debugging command in the user view to debug PIM
and locate the fault.
Procedure
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] all command
in the user view to enable all the debugging of PIM.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] event
[ advanced-acl-number ] command in the user view to enable the debugging of PIM events.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] routing-
table [ advanced-acl-number ] command in the user view to enable the debugging of PIM
routes.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] neighbor
[ basic-acl-number | [ receive | send ] ] * command in the user view to enable the debugging
of PIM neighbors.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] assert
debugging of PIM Assert.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] rp [ receive |
send ] command in the user view to enable the debugging of the PIM BSR and the
debugging of PIM RP.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] join-prune
debugging of PIM Join/Prune.

l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] register

[ advanced-acl-number ] command in the user view to enable the debugging of PIM
Register.
l Run the debugging pim [ vpn-instance vpn-instance-name | all-instance ] msdp
[ advanced-acl-number ] command in the user view to enable the debugging of the
information exchanged between PIM and MSDP.
l Run the debugging pim bfd { all | create | delete | event } command in the user view to
enable the debugging of PIM BFD.
----End

Configuration examples are provided to show how to construct a basic PIM-SM network and
configure basic functions of PIM-SM.
6.16.1 Example for Configuring the PIM-SM Network
As shown in Figure 6-2, multicast is deployed on the network of an Internet Service Provider
(ISP). The Interior Gateway Protocol (IGP) is deployed on the network. The unicast routing
routes work normally and are connected to the Internet. The routers on the network need to be
configured properly so that hosts can receive the video on demand (VOD) in multicast mode.
Figure 6-2 Networking diagram for configuring PIM-SM multicast network

Ethernet
SwitchA N1
GE3/0/0 GE2/0/0 Receiver
Ethernet
GE1/0/0
PIM-SM HostA
GE2/0/0 SwitchE
GE3/0/0 Leaf networks
Source GE3/0/0
GE1/0/0 GE2/0/0
GE4/0/0 GE2/0/0
SwitchD Receiver
GE4/0/0 GE1/0/0 GE1/0/0
SwitchB
GE2/0/0 HostB
N2
GE1/0/0 Ethernet
SwitchC
GE 2/0/0 VLANIF 101 10.110.1.1/24
GE 3/0/0 VLANIF 200 192.168.1.1/24
GE 2/0/0 VLANIF 102 10.110.2.1/24

GE 2/0/0 VLANIF 400 192.168.3.1/24

GE 2/0/0 VLANIF 200 192.168.1.2/24
GE 3/0/0 VLANIF 103 10.110.5.1/24
GE 4/0/0 VLANIF 104 10.110.4.1/24
SwitchE GE 1/0/0 VLANIF 400 192.168.3.2/24
GE 2/0/0 VLANIF 300 192.168.2.2/24
GE 3/0/0 VLANIF 100 192.168.9.2/24
GE 4/0/0 VLANIF 500 192.168.4.1/24
The ISP network connects to the Internet. The PIM-SM protocol is used to configure the
multicast function, which facilitates service expansion. The ASM and SSM models provide
multicast services. The configuration roadmap is as follows:
1. Configure the IP addresses of interfaces and the unicast routing protocol. PIM is an intra-
domain multicast routing protocol that depends on a unicast routing protocol. The multicast
routing protocol can work normally after the unicast routing protocol works normally.
2. Enable multicast on all Switches providing multicast services. Before configuring other
PIM-SM functions, you must enable the multicast function.
3. Enable PIM-SM on all the interfaces of Switches. After PIM-SM is enabled, you can
configure other PIM-SM functions.
NOTE
If IGMP is also required on this interface, PIM-SM must be enabled before IGMP is enabled. The
configuration order cannot be reversed; otherwise, the configuration of PIM fails.
4. Enable IGMP on the interfaces of Switches connected to hosts. A receiver can join and
leave a multicast group freely by sending an IGMP message. The leaf Switches maintain
the multicast membership through IGMP.
5. Enable the PIM silent function on interface that is directly connected to hosts. In this
manner, malicious hosts are prevented from simulating PIM Hello messages and security
of multicast routers is ensured.
NOTE
PIM silent is applicable only to the interfaces of a Switch directly connected to the host network
segment that is connected only to this Switch.
6. Configure the RP. The RP is a root node of an RPT on the PIM-SM network. It is
recommended that you configure the RP on a device that has more multicast flows, for
example, SwitchE in Figure 6-2.
NOTE
l After creating an (*, G) entry according to the new multicast membership, the DR on the user
side sends Join/Prune messages towards the RP and updates the shared tree on the path.
l When a multicast data source starts to send data to groups, the DR unicasts the Register message
to the RP. After receiving the Register message, the RP decapsulates it and then forwards it to
other multicast members along the shared tree. At the same time, the RP sends a Register-Stop
message to the DR on the multicast source side. After the Register-Stop is performed, the RPT
can be switched to the SPT.

7. (Optional) Set the BSR boundary on the 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.
8. (Optional) Configure range of SSM group addresses 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.
NOTE
This configuration example describes only the commands used to configure PIM-SM.
Data Preparation

l Address of multicast group S: 10.110.5.100/24
l Version of the IGMP protocol running between routers and hosts: IGMPv3
l Range of SSM group addresses: 232.1.1.0/24
Procedure
Step 1 Configure the IP address of each interface and the unicast routing protocol.
# Configure IP addresses and masks of interfaces on the Switches according to Figure 6-2.
Configure OSPF between Switches to ensure that the Switches can communicate at the network
layer and update routes through the unicast routing protocol.
For details on how to configure IP addresses of interfaces, see IP Addresses Configuration in

the Quidway S9300 Terabit Routing Switch Configuration Guide - IP Service. For details on
how to configure OSPF, see OSPF Configuration in the Quidway S9300 Terabit Routing Switch
Configuration Guide - IP Routing.
Step 2 Enable multicast on all Switches and PIM-SM on all interfaces.
# Enable multicast on all the Switches and enable PIM-SM on all interfaces. The configurations
of SwitchB, SwitchC, and SwitchD are similar to the configuration of SwitchA, and are not
provided here.
Step 3 Enable IGMP on the interfaces connected to hosts.
# Enable IGMP on the interface connecting SwitchA to hosts. The configurations of SwitchB,
SwitchC, and SwitchD are similar to configuration of SwitchA, and are not provided here.
[SwitchA-Vlanif101] igmp version 3

Step 4 Enable PIM silent on SwitchA.

[SwitchA-Vlanif101] pim silent
Step 5 Configure the RP.

NOTE
The RP can be configured in two modes: the static RP and the 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 change the parameter values to
specify which RP is preferred.
This example shows how to configure 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 on one or more Switches in the PIM-SM domain. In this example,
set the service range of the RP and specify the locations of the C-BSR and the C-RP on
SwitchE.
[SwitchE] acl number 2008
[SwitchE-acl-basic-2008] rule permit source 225.1.1.0 0.0.0.255
[SwitchE-acl-basic-2008] quit
[SwitchE] pim
[SwitchE-pim] c-bsr vlanif 100
[SwitchE-pim] c-rp vlanif 100 group-policy 2008 priority 0
# Configure static RPs on all Switches. The configurations of SwitchB, SwitchC, SwitchD, and
SwitchE are similar to configuration on SwitchA, and are not provided here.
NOTE
If you enter preferred to the right of static-rp X.X.X.X, the static RP is selected as the RP in the PIM-SM
domain.
[SwitchA] pim
[SwitchA-pim] static-rp 192.168.2.2
Step 6 Configure the BSR boundary on the interface connecting SwitchD to the Internet.
[SwitchD-Vlanif104] pim bsr-boundary
[SwitchD-Vlanif104] quit
Step 7 Configure the range of SSM group addresses.
# Set the range of SSM group addresses to 232.1.1.0/24 on all Switches. The configurations of
SwitchB, SwitchC, SwitchD, and SwitchE are the same as the configuration of SwitchA, and
[SwitchA-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[SwitchA] pim
[SwitchA-pim] ssm-policy 2000
# Run the display pim interface command. You can view the configuration and running status
of PIM on the interface. For example, the PIM information displayed on SwitchC is as follows:
<SwitchC> display pim interface
Vlanif102 up 0 30 1 10.110.2.2 (local)
Vlanif400 up 1 30 1 192.168.3.1

# Run the display pim bsr-info command to view information about BSR election on the
Switches. For example, the BSR information on SwitchA and SwitchE (including the C-BSR
information on SwitchE) is as follows:
<SwitchA> display pim bsr-info
Elected AdminScoped BSR Count: 0
Elected BSR Address: 192.168.9.2
Priority: 0
Hash mask length: 30
State: Accept Preferred
Scope: Not scoped
Uptime: 01:40:40
Expires: 00:01:42
C-RP Count: 1
<SwitchE> display pim bsr-info

Elected BSR Address: 192.168.9.2
Priority: 0
Mask length: 30
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 is: 192.168.9.2
Priority: 0
State:Elected
Scope: Not scoped
Wait to be BSR: 0
# Run the display pim rp-info command to view the RP information on the Switches. For
example, the RP information displayed on SwitchA is as follows:
<SwitchA> display pim rp-info
PIM-SM BSR RP information:
Group/MaskLen: 225.1.1.0/24
RP: 192.168.9.2
Priority: 0
Uptime: 00:45:13
Expires: 00:02:17
PIM SM static RP information:
Static RP: 192.168.2.2
# Run the display pim routing-table command. You can view the PIM multicast routing table.
Host A needs to receive the information from group 225.1.1.1/24, and HostB needs to receive
the information sent by the source 10.110.5.100/24 to the group 232.1.1.1/24. The displayed
information is as follows:
[SwitchA] display pim routing-table
(*, 225.1.1.1)
RP: 192.168.9.2
Protocol: pim-sm, Flag: WC
UpTime: 00:13:46
Upstream interface: vlanif100,
RPF neighbor: 192.168.9.2
1: vlanif101

(10.110.5.100, 225.1.1.1)
RP: 192.168.9.2
Protocol: pim-sm, Flag: SPT ACT
UpTime: 00:00:42
Upstream interface: vlanif200
1: vlanif101
Protocol: pim-sm, UpTime: 00:00:42, Expires:-
[SwitchB] display pim routing-table
(*, 232.1.1.1)
RP: 192.168.9.2
UpTime: 00:10:12
1: vlanif102
(10.110.5.100, 232.1.1.1)
RP: 192.168.9.2
UpTime: 00:00:42
1: vlanif102
[SwitchD] display pim routing-table

(10.110.5.100, 225.1.1.1)
RP: 192.168.9.2
UpTime: 00:00:42
1: vlanif200
(10.110.5.100, 232.1.1.1)
Protocol: pim-ssm, Flag:
UpTime: 00:01:20
1: vlanif500
Protocol: pim-ssm, UpTime: 00:01:20, Expires:-
[SwitchE] display pim routing-table


(*, 225.1.1.1)
RP: 192.168.9.2 (local)
UpTime: 00:13:16
Upstream interface: Register
1: vlanif100
Protocol: pim-sm, UpTime: 00:13:16, Expires: 00:03:22
(10.110.5.100, 232.1.1.1)
UpTime: 00:01:22
1: vlanif400
Protocol: pim-ssm, UpTime: 00:01:22, Expires:-
[SwitchC] display pim routing-table

Total 1 (S, G) entry
(10.110.5.100, 232.1.1.1)
UpTime: 00:01:25
1: vlanif102
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 101 200
#
#
acl number 2000
#
interface Vlanif100
ip address 192.168.9.1 255.255.255.0
pim sm
#
interface Vlanif101
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp version 3
pim silent
#
interface vlanif 200

ip address 192.168.1.1 255.255.255.0

pim sm
#
#
#
#
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.9.0 0.0.0.255
#
pim
static-rp 192.168.2.2
ssm-policy 2000
#
return
#
sysname SwitchB
#
#
vlan batch 102 300
#
acl number 2000
#
interface Vlanif102
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
igmp version 3
#
interface Vlanif300
ip address 192.168.2.1 255.255.255.0
pim sm
#
#
#
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
ssm-policy 2000
#
return
#
sysname SwitchC

#
vlan batch 102 400
#
#
acl number 2000
#
interface Vlanif102
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
igmp version 3
#
interface Vlanif400
ip address 192.168.3.1 255.255.255.0
pim sm
#
#
#
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
ssm-policy 2000
#
return
#
sysname SwitchD
#
vlan batch 103 104 200 500
#
#
acl number 2000
#
interface Vlanif103
ip address 10.110.5.1 255.255.255.0
pim sm
#
interface Vlanif104
ip address 10.110.4.1 255.255.255.0
pim sm
pim bsr-boundary
#
interface Vlanif200
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Vlanif500
ip address 192.168.4.2 255.255.255.0
pim sm
#
#


#
#
#
ospf 1
area 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.4.0 0.0.0.255
#
pim
static-rp 192.168.2.2
ssm-policy 2000
#
return
l Configuration file of SwitchE
#
sysname SwitchE
#
vlan batch 100 300 400 500
#
#
acl number 2000
#
acl number 2008
#
interface Vlanif100
ip address 192.168.9.2 255.255.255.0
pim sm
#
interface Vlanif300
ip address 192.168.2.2 255.255.255.0
pim sm
#
interface Vlanif400
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface Vlanif500
ip address 192.168.4.1 255.255.255.0
pim sm
#
#
#
#
#
ospf 1

area 0.0.0.0
network 192.168.3.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.9.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
c-bsr vlanif 100
c-rp vlanif 100 group-policy 2005 priority 0
static-rp 192.168.2.2
ssm-policy 2000
#
return
6.16.2 Example for Configuring SPT Switchover in PIM-SM

Domain
Receivers can receive the VOD information in multicast mode. The entire PIM network adopts
a single BSR administrative domain. By default, after receiving the first multicast data packet,
the RP and the DR on the receiver side perform the SPT switchover, finding the optimal path to
receive the multicast information from the multicast source. If the receiver requires that the SPT
switchover be performed after the traffic reaches the threshold, you need to configure the SPT
switchover function.
As shown in Figure 6-3, you need to configure the Switches properly. In this way, HostA on
the leaf network then can receive multicast data from the RP (GE1/0/0 of SwitchA). When the
transmission rate of multicast packets reaches 1024 kbit/s, the SPT switchover is performed.
After the SPT switchover, the path through which HostA receive multicast packets is Source-
SwitchB-SwitchC--HostA.
Figure 6-3 Networking diagram for performing the SPT switchover in PIM-SM domain
SwitchA
GE2/0/0
Ethernet GE1/0/0
PIM-SM
GE2/0/0 Leaf networks
GE1/0/0
Source GE3/0/0 GE1/0/0
Receiver
GE3/0/0 GE2/0/0
SwitchB SwitchC
HostA
Ethernet

GE 2/0/0 VLANIF 200 192.168.3.1/24

GE 2/0/0 VLANIF 200 192.168.3.2/24

GE 3/0/0 VLANIF 101 10.110.5.1/24
GE 2/0/0 VLANIF 102 10.110.2.1/24
GE 3/0/0 VLANIF 300 192.168.2.2/24
1. Configure the IP addresses of interfaces and the unicast routing protocol.
2. Enable the multicast function on all Switches, enable PIM-SM on all interfaces, and enable
IGMP on the interfaces connected to hosts.
3. Configure the same static RP on each Switch.
4. Perform the SPT switchover on SwitchC.
Data Preparation
l Address of multicast source S: 10.110.5.100/24
l Version of IGMP running between SwitchC and the leaf network: 2
Procedure
# Based on Figure 6-3, configure the IP address and mask of each interface on Switches; connect
the Switches through OSPF to ensure that SwitchA, SwitchB, and SwitchC can connect to each
other at the network layer and can dynamically update routes through the unicast routing
protocol.
how configure OSPF, see OSPF Configuration in the Quidway S9300 Terabit Routing Switch
Step 2 Enable multicast on all Switches, PIM-SM on all interfaces, and IGMP on the interfaces
connected to hosts.
# Enable multicast on all Switches, PIM-SM on all interfaces, and IGMP on the interface through
which SwitchC is connected to the leaf network. The configurations of SwitchA and SwitchB
are similar to the configuration of SwitchC, and are not provided here.
[SwitchC] multicast routing-enable
[SwitchC] interface vlanif 102
[SwitchC-Vlanif102] pim sm
[SwitchC-Vlanif102] igmp enable
[SwitchC-Vlanif102] igmp version 2
[SwitchC-Vlanif102] quit

Step 3 Configure the static RP.

# Configure the static RP on SwitchA, SwitchB, and SwitchC. The configurations of SwitchB
and SwitchC are similar to configuration of SwitchA, and are not provided here.
[SwitchA] pim
Step 4 Configure the threshold of the SPT switchover.

# Configure SwitchC to perform the SPT switchover when the transmission rate of multicast
packets reaches 1024 kbit/s.
[SwitchC] pim
[SwitchC-pim] spt-switch-threshold 1024
[SwitchC-pim] quit

# The multicast source begins to send data to the multicast group, and HostA can receive the
data from the source. When the rate is smaller than 1024 kbit/s, you can run the display pim
routing-table command to view the PIM multicast routing table on SwitchC. You can find that
the upstream neighbor is SwitchA. The displayed information is as follows:
<SwitchC> display pim routing-table
(*, 225.1.1.1)
RP: 192.168.1.1
UpTime: 00:13:46
1: vlanif102
(10.110.5.100, 225.1.1.1)
RP: 192.168.1.1
Protocol: pim-sm, Flag: ACT
UpTime: 00:00:42
1: vlanif102
# When the rate is higher than 1024 kbit/s, you can run the display pim routing-table command
to view the PIM multicast routing table on SwitchC. You can find that the upstream neighbor is
SwitchB. The displayed information is as follows:
(*, 225.1.1.1)
RP: 192.168.1.1

UpTime: 00:13:46
1: vlanif102,
(10.110.5.100, 225.1.1.1)
RP: 192.168.1.1
Protocol: pim-sm, Flag:RPT SPT ACT
UpTime: 00:00:42
1: vlanif102
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 200
#
#
interface Vlanif100
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface Vlanif200
ip address 192.168.3.1 255.255.255.0
pim sm
#
#
#
pim
static-rp 192.168.1.1
#
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

#
sysname SwitchB
#
#
#
interface Vlanif101
ip address 10.110.5.1 255.255.255.0

pim sm
#
interface Vlanif200
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface Vlanif300
ip address 192.168.2.1 255.255.255.0
pim sm
#
#
#
#
pim
static-rp 192.168.1.1
#
ospf 1
area 0.0.0.0
network 10.110.5.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 SwitchC
#
#
#
interface Vlanif100
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Vlanif102
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
igmp version 2
#
interface Vlanif300
ip address 192.168.2.2 255.255.255.0
pim sm
#
#
#
#
pim
spt-switch-threshold 1024
static-rp 192.168.1.1

#
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.2.0 0.0.0.255
#
return
6.16.3 Example for Configuring PIM BFD
On the multicast network shown in Figure 6-4, PIM-SM is run between Switches. Hosts receive
the VOD information from the multicast source. SwitchA is the DR on the source side.
SwitchB and SwitchC are connected to the segment where hosts reside. When the DR changes,
other Switches on the network segment can detect the change of the DR quickly.
You can set up the BFD session on the network segment where the host is located to respond to
the changes of the DR quickly. In addition, you can configure the DR switchover delay. In this
case, when a Switch is added to the network segment and may become a DR, the multicast
routing table of the original DR is reserved until the routing entries of the new DR are created.
Therefore, the packet loss due to the delay in creating multicast entries is prevented.
NOTE
After the delay of PIM DR switchover is set, the downstream receiver may receive two copies of the same
data during the DR switchover and the assert mechanism will be triggered. If you do not want to trigger
the assert mechanism, you do not need to set the DR switchover delay.
Figure 6-4 Configuring the PIM BFD networking in the shared network segment
SwitchA
Source
10.1.7.1/24 PIM-SM GE1/0/0
SwitchC
GE1/0/0
GE2/0/0
SwitchB
GE2/0/0
VLAN100
User1 User2

1. Configure PIM BFD on the interfaces that connect Switches to the network segment where
the host is located.
2. Set the PIM DR switchover delay on the interfaces that connect Switches to the network
segment where the host is located.
Data Preparation
l Parameters of PIM BFD sessions
l PIM DR switchover delay
NOTE
This configuration example describes only the commands used to configure PIM-SM BFD.
Procedure
Step 1 Configure the IP address of each interface and the unicast routing protocol.
# Configure IP addresses and masks of interfaces on the Switches according to Figure 6-4.
Configure OSPF between Switches to ensure that the Switches can communicate at the network
layer and update routes through the unicast routing protocol.
how configure OSPF, see OSPF Configuration in the Quidway S9300 Terabit Routing Switch
Step 2 Enable BFD globally and configure PIM BFD in the interface view.
# Enable BFD globally on SwitchB and SwitchC, enable PIM BFD on the interfaces that are
connected to the network segment where the host resides, and set PIM BFD parameters. The
configuration on SwitchC is similar to the configuration on SwitchB and is not provided here.
[SwitchB] bfd
[SwitchB-bfd] quit
[SwitchB] interface vlanif 100
[SwitchB-Vlanif100] pim bfd enable
[SwitchB-Vlanif100] pim bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 3
Step 3 Configure the PIM DR switchover delay.

# Configure PIM DR switchover delay on SwitchB and SwitchC. The configuration on
SwitchC is similar to the configuration on SwitchB and is not provided here.
[SwitchB-Vlanif100] pim timer dr-switch-delay 20
[SwitchB-Vlanif100] quit
[SwitchB] quit

# Run the display pim interface verbose command, and you can view detailed information
about the interface that runs PIM. The information about the interface that runs PIM on
SwitchB indicates that the DR on the network segment where the host is located is SwitchC.
PIM BFD is enabled on the interface and the switchover delay is set.
<SwitchB> display pim interface vlanif100 verbose
Interface: Vlanif100, 10.1.1.1

PIM version: 2
PIM mode: Sparse
PIM state: up
PIM DR: 10.1.1.2
PIM neighbor count: 1
PIM Hello interval: 30 s
PIM LAN delay (negotiated): 500 ms
PIM Hello override interval (negotiated): 2500 ms
PIM Hello override interval (configured): 2500 ms
PIM Silent: disabled
PIM neighbor tracking (negotiated): disabled
PIM generation ID: 0XF5712241
PIM Hello hold interval: 105 s
PIM Hello assert interval: 180 s
PIM triggered Hello delay: 5 s
PIM BSR domain border: disabled
PIM BFD: enable
PIM BFD min-tx-interval: 100 ms
PIM BFD min-rx-interval: 100 ms
PIM BFD detect-multiplier: 3
PIM dr-switch-delay timer : 20 s
Number of routers on network not using DR priority: 0
Number of routers on network not using LAN delay: 0
Number of routers on link not using neighbor tracking: 2
# Run the display pim bfd session command to display information about the BFD session on
each Switch. You can check whether the BFD session is set up on each Switch.
<SwitchB> display pim bfd session
Total 1 BFD session Created
Vlanif100 (10.1.1.1): Total 1 BFD session Created
Neighbor ActTx(ms) ActRx(ms) ActMulti Local/Remote State

10.1.1.2 100 100 3 8192/8192 Up
# Run the display pim routing-table command to view the PLM routing table. SwitchC
functions as the DR. The (S, G) and (*, G) entries exist. The displayed information is as follows:
(*, 225.1.1.1)
RP: 10.1.5.2
UpTime: 00:13:46
1: Vlanif100,
(10.1.7.1, 225.1.1.1)
RP: 10.1.5.2
UpTime: 00:00:42


1: Vlanif100
----End
Configuration Files
l SwitchA needs to be configured with only basic PIM SM functions. The configuration file
is not provided here.
l The following is the configuration file of SwitchB. The configuration file of SwitchC is
similar to the configuration file of SwitchB, and is not provided here.
#
sysname SwitchB
#
vlan batch 100 200
#
#
bfd
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
pim sm
igmp enable
pim bfd enable
pim bfd min-tx-interval 100 min-rx-interval 100
pim timer dr-switch-delay 20
#
interface Vlanif200
ip address 10.1.2.1 255.255.255.0
pim sm
#
#
#
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
6.16.4 Example for Configuring PIM GR
In the multicast application, if the active/standby switchover occurs on a device, the new master
MPU deletes the multicast forwarding entries of the LPUs and relearns the PIM routes and
multicast forwarding entries. During this process, multicast traffic is interrupted.
The PIM GR function on an IPTV network can protect the core devices and edge devices. When
an active/standby switchover occurs, the PIM GR function ensures that the multicast data is
forwarded normally. In this way, the fault tolerance capability of the devices on the IPTV
network is improved.

As shown in Figure 6-5, multicast services are deployed on the network. When SwitchC enabled
with the PIM GR function forwards multicast data to the receiver, the master MPU backs up the
PIM routes and Join/Prune messages to be sent to the upstream device to the slave MPU. When
the active/standby switchover occurs on SwitchC, the LPUs maintain the existing forwarding
entries to ensure uninterrupted forwarding of multicast data. The receiver can always receive
multicast data from the source during the active/standby switchover.
Figure 6-5 Networking diagram of PIM GR
Ethernet
Leaf networks
SwitchA
GE1/0/0 GE2/0/0
Source
GE2/0/0 GE1/0/0 GE1/0/0 GE2/0/0
SwitchB SwitchC
Receiver
PIM-SM HostA
Ethernet
Device Physical interface VLANIF interface IP address
SwitchA GE1/0/0 VLANIF 10 192.168.2.1/24
GE2/0/0 VLANIF 20 10.110.1.1/24
SwitchB GE1/0/0 VLANIF 30 192.168.2.2/24
GE2/0/0 VLANIF 40 192.168.4.1/24
SwitchC GE1/0/0 VLANIF 50 192.168.4.2/24
GE2/0/0 VLANIF 60 10.110.2.1/24
1. Configure the IP addresses and unicast routing protocols on the physical interfaces of the
switch matching the VLANIF interfaces.
2. Enable the unicast GR function on each switch and set the GR period.
3. Enable the multicast function, enable PIM-SM on the interface of the switch, and enable
IGMP on the interface connecting switch to the host.
4. Configure an RP. Configure same static RPs on the switches.
5. Enable the PIM GR function on SwitchC and set the GR period.
Data Preparation
l Multicast source address 10.110.1.100

l Multicast group address 225.1.1.1

l Unicast GR period
l PIM GR period
Procedure
Step 1 Configure the IP addresses and unicast routing protocols on the physical interfaces of the
switch matching the VLANIF interfaces.
# Configure the IP address and mask on each interface of the switches according to Figure
6-5. The switches are connected to each other through OSPF. SwitchA, SwitchB, and SwitchC
can communicate with each other at the network layer.

how to configure OSPF, see OSPF Configuration in the Quidway S9300 Terabit Routing Switch
Step 2 Enable the unicast GR function on each switch and set the unicast GR period.
# Enable the unicast GR function on all the switches and set the unicast GR period to 200 seconds.
The configurations of SwitchA and SwitchB are similar to the configuration of SwitchC, and
[SwitchC] ospf 1
[SwitchC-ospf-1] opaque-capability enable
[SwitchC-ospf-1] graceful-restart
[SwitchC-ospf-1] graceful-restart period 200
[SwitchC-ospf-1] quit
Step 3 Enable the multicast function, enable PIM SM on each interface of the switch, and enable IGMP
on the interfaces connecting switch to the host.
# Enable the multicast function on all switches, and enable PIM SM on each interface of the
switch, and enable IGMP on the interface connecting switchC to the host. The configurations
of SwitchA and SwitchB are similar to the configuration of SwitchC, and are not provided here.
[SwitchC] interface gigabitethernet 2/0/0
[SwitchC-GigabitEthernet2/0/0] port hybrid pvid vlan 60
[SwitchC-GigabitEthernet2/0/0] port hybrid untagged vlan 60
[SwitchC-GigabitEthernet2/0/0] quit
[SwitchC] interface gigabitethernet 1/0/0
[SwitchC-GigabitEthernet1/0/0] port hybrid pvid vlan 50
[SwitchC-GigabitEthernet1/0/0] port hybrid untagged vlan 50
[SwitchC-GigabitEthernet1/0/0] quit
# Create a loopback interface on SwitchA and enable PIM SM on the interface.

[SwitchA] interface loopback 0
[SwitchA-Loopback0] ip address 1.1.1.1 255.255.255.255
[SwitchA-Loopback0] pim sm
[SwitchA-Loopback0] quit

# Configure the static RP on all the switches. The configurations of SwitchB and SwitchC are
similar to the configuration of SwitchA, and are not provided here.
[SwitchA] pim
[SwitchA-pim] quit
Step 5 Enable PIM GR and set the PIM GR period.

# Enable the PIM GR function on SwitchC and set the PIM GR period to 300 seconds.
[SwitchC] pim
[SwitchC-pim] graceful-restart
[SwitchC-pim] graceful-restart period 300
[SwitchC-pim] quit

# Multicast source 10.110.1.100 sends data to multicast group 225.1.1.1. Host A sends an IGMP
Report message to join the multicast group and it can receive multicast data from the multicast
source. Before SwitchC performs an active/standby switchover, run the display pim routing-
table command on SwitchB and SwitchC to view the multicast routing tables. The command
output is as follows:
<SwitchB> display pim routing-table
(*, 225.1.1.1)
RP: 1.1.1.1
UpTime: 01:52:38
1: Vlanif40
(10.110.1.100, 225.1.1.1)
RP: 1.1.1.1
UpTime: 01:52:38
upstream neighbor: 192.168.2.1
1: Vlanif40
(*, 225.1.1.1)
RP: 1.1.1.1
UpTime: 01:51:24
1: Vlanif60
Protocol: igmp, UpTime: 01:51:24, Expires: -
(10.110.1.100, 225.1.1.1)

RP: 1.1.1.1
UpTime: 01:51:24
1: Vlanif60
Protocol: pim-sm, UpTime: 01:51:24, Expires: -
# Run the active/standby switchover commands on SwitchC.

[SwitchC] slave switchover
# After SwitchC performs an active/standby switchover, during PIM GR, run the display pim
routing-table command on SwitchB and SwitchC to view the routing tables. The command
(*, 225.1.1.1)
RP: 1.1.1.1
UpTime: 02:52:38
1: Vlanif40
(10.110.1.100, 225.1.1.1)
RP: 1.1.1.1
UpTime: 02:52:38
1: Vlanif40
(*, 225.1.1.1)
RP: 1.1.1.1
UpTime: 02:51:24
1: Vlanif60
Protocol: igmp, UpTime: 02:51:24, Expires: -
(10.110.1.100, 225.1.1.1)
RP: 1.1.1.1
UpTime: 02:51:24


1: Vlanif60
On a multicast network, the downstream switch periodically sends Join/Prune messages to the
upstream device to update the timeout period of PIM routing entries on the upstream, thereby
ensuring normal multicast data forwarding.
If the GR function is not configured on SwitchC, the new master MPU deletes the multicast
forwarding entries of the LPUs, receives the IGMP Report messages sent by hosts, and creates
the PIM routing entries. During the active/standby switchover, multicast traffic is interrupted.
The preceding information indicates that after SwitchC performs an active/standby switchover,
the downstream interface on SwitchB remains unchanged. That is, after SwitchC performs the
active/standby switchover, SwitchC sends the backup Join messages to the upstream device. In
this way, the multicast forwarding entries are maintained during GR to ensure nonstop multicast
data forwarding.
During the restoration of multicast routing entries on SwitchC, users can still receive multicast
data normally and services are not affected.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
#
interface Vlanif10
ip address 192.168.2.1 24
pim sm
#
interface Vlanif20
ip address 10.110.1.1 24
pim sm
#
#
#
interface Loopback0
ip address 1.1.1.1 255.255.255.255
pim sm
#
ospf 1
opaque-capability enable
graceful-restart period 200
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 10.110.1.0 0.0.0.255
network 1.1.1.1 0.0.0.0
#
pim
static-rp 1.1.1.1
#

return
#
sysname SwitchB
#
vlan batch 30 40
#
#
interface Vlanif30
ip address 192.168.2.2 24
pim sm
#
interface Vlanif40
ip address 192.168.4.1 24
pim sm
#
#
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
static-rp 1.1.1.1
#
return
#
sysname SwitchC
#
vlan batch 50 60
#
#
interface Vlanif50
ip address 192.168.4.2 24
pim sm
#
interface Vlanif60
igmp enable
ip address 10.110.2.1 24
pim sm
#
#
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#

pim
static-rp 1.1.1.1
graceful-restart
#
return

Configuration Guide - Multicast 7 MSDP Configuration
7 MSDP Configuration
About This Chapter
The MSDP protocol is used to implement multicast routing and data forwarding between PIM-
SM domains and anycast RP in a PIM-SM domain.
7.1 MSDP Overview
MSDP functions to set up an MSDP peer relationship between RPs in different PIM-SM
domains. MSDP peers exchange (S, G) information by sending SA messages. In this manner,
MSDP peers share multicast source information and hosts can receive multicast data from the
multicast sources in another PIM-SM domain.
7.2 MSDP Features Supported by the S9300
MSDP is used to implement PIM-SM inter-domain multicast and anycast RP in a PIM-SM
domain. You can control connections between MSDP peers, adjust SA message parameters, and
configure authentication for MSDP peers and filtering policies for SA messages to enhance
MSDP security. The system supports multi-instance MSDP.
7.3 Configuring PIM-SM Inter-domain Multicast
This section describes how to set up an MSDP peer relationship between PIM-SM domains in
an AS and how to configure MSDP peers.
7.4 Configuring an Anycast RP in a PIM-SM Domain
Anycast RP indicates that when multiple RPs with the same address reside in the same PIM-SM
domain and MSDP peer relationships are set up between these RPs, IP routing automatically
selects the topologically closest RP for each source and receiver. In this manner, burdens on a
single RP are released, RP backup is implemented, and the forwarding path is optimized.
7.5 Managing MSDP Peer Connections
MSDP peers should set up TCP connections. You can then flexibly control the sessions set up
between MSDP peers by closing or re-establishing TCP connections. You can also adjust the
interval for retrying to set up a TCP connection between MSDP peers.
7.6 Configuring SA Cache
An SA cache is used to save the (S, G) information carried in SA messages locally. When a
device needs to receive multicast data, it directly obtains available (S, G) information from the
SA cache.
7.7 Configuring the SA Request
If the capacity of the SA cache enabled on the remote MSDP peer is too large, configuring
"sending SA Request message" on the local device can shorten the time taken by a receiver to

obtain multicast source information. You can configure filtering rules for receiving SA Request
messages on a specified remote MSDP peer.
7.8 Transmitting Burst Multicast Data Between Domains
By default, an SA message carries only (S, G) information. Then, if burst multicast data need
be transmitted between domains, you can configure multicast data encapsulation for an SA
message on the source RP. In addition, you can set the TTL threshold to limit the transmission
scope of multicast data encapsulated in an SA message.
7.9 Configuring the Filtering Rules for SA Messages
By default, a device receives all SA messages that pass the RPF check, and forwards the SA
messages to all MSDP peers. To control the transmission of SA messages among MSDP peers,
you can configure rules to filter the constructing, receiving, and forwarding SA messages.
7.10 Configuring MSDP Authentication
MSDP peer authentication contains MSDP MD5 authentication and Key-Chain authentication.
You can choose either authentication mode.
7.11 Maintaining MSDP
Maintaining MSDP involves clearing MSDP peer statistics and (S, G) information in the SA
cache, and monitoring MSDP running status.
Configuration examples are provided to show how to implement PIM-SM inter-domain
multicast through MBGP, how to implement inter-AS multicast through static RPF peers, and
how to configure anycast RP in a PIM-SM domain.

7.1 MSDP Overview

MSDP functions to set up an MSDP peer relationship between RPs in different PIM-SM
domains. MSDP peers exchange (S, G) information by sending SA messages. In this manner,
MSDP peers share multicast source information and hosts can receive multicast data from the
multicast sources in another PIM-SM domain.
In the general PIM-SM mode, a multicast source registers only with the local rendezvous point
(RP). The information on the inter-domain multicast sources is isolated. The RP knows only the
source in its domain, establishes a multicast distribution tree (MDT) in its domain, and distributes
the data sent by the source to the local users.
A mechanism is required to enable the local RP to share the information on the multicast sources
of other domains. With the mechanism, the local RP can send Join messages to the multicast
sources of other domains and establish MDTs. Therefore, multicast packets can be transmitted
across domains, and hosts in the local domain can receive data sent by multicast sources in other
domains.
The Multicast Source Discovery Protocol (MSDP) is an inter-area multicast solution based on
multiple interconnected PIM-SM domains, and can solve the preceding problem.
MSDP achieves this objective by setting up the MSDP peer relationship between RPs of different
domains. MSDP peers share the information on multicast sources by sending Source Active
(SA) messages. They transmit the (S, G) information from the RP that the source S registers
with to other RPs connected to members of G.
MSDP peers are connected through the TCP connection. MSDP peers perform the RPF check
on received SA messages.
NOTE
MSDP is applicable only to PIM-SM domains, and useful only for the Any-Source Multicast (ASM) mode.
7.2 MSDP Features Supported by the S9300

MSDP is used to implement PIM-SM inter-domain multicast and anycast RP in a PIM-SM
domain. You can control connections between MSDP peers, adjust SA message parameters, and
configure authentication for MSDP peers and filtering policies for SA messages to enhance
MSDP security. The system supports multi-instance MSDP.
PIM-SM Inter-Domain Multicast

When a multicast network is divided into multiple PIM-SM domains, MSDP is used to connect
RPs in each domain to share the multicast source information. In this manner, hosts in a domain
can receive multicast data sent by multicast sources in other domains.
You can configure a loopback interface as a C-RP or a static RP or specify the address of a
loopback interface as a logical RP address for SA messages.
PIM-SM Intra-Domain Anycast RP

After anycast RP is applied to a PIM-SM domain, the multicast source registers with the nearest
RP and receivers send Join messages to the nearest RP. This reduces the burden of a single RP,
implements RP backup, and optimizes the forwarding path.

You can use a loopback interface as a interface of C-RP or static RP and specify the logical RP
address for an SA message.
Configuring Control Parameters for Maintaining MSDP Peer Connections

In the S9300, you can set up and tear down an MSDP session, and configure the period for
retrying to send TCP connection requests to the remote MSDP peers.
Configuring SA Cache
By default, SA-Cache is enabled on switchs. Therefore, switchs can locally store the (S, G)
information carried in SA messages. When required to receive the multicast data, the switchs
can obtain the (S, G) information from the SA-Cache.
You can set the maximum number of cached (S, G) entries, which can effectively prevent the
Denial of Service (DoS) attack.
You can disable SA-Cache on a switch. After the SA-Cache on a switch is disabled, the
switch does not locally store the (S, G) information carried in SA messages. When the switch
needs to receive multicast data, it needs to wait for the SA message to be sent by its MSDP peer
in the next period. This causes a delay for receivers to obtain multicast source information.
Controlling SA Requests
Certain switchs cannot be enabled with SA Cache or the capacity of SA Cache on these
switchs is too small. When these switchs need to receive multicast data, they cannot immediately
obtain the valid (S, G) information but need to wait for the SA message to be sent by their MSDP
peers in the next period.
If SA Cache is enabled on the remote MSDP peer and the capacity of the SA Cache is large, you
can configure "sending SA request messages" on the local switch to reduce the period during
which receivers obtain multicast source information.
At the same time, you can also configure the filtering rules for receiving SA request messages
on the remote MSDP peers.
Transmitting Burst Multicast Data

When the interval for a certain multicast source to send multicast data is longer than the timeout
period of an (S, G) entry, the source DR can only encapsulate burst multicast data in Register
messages and send them to the source RP. The source RP uses SA messages to transmit (S, G)
information to the remote RP. The remote RP then sends an (S, G) Join message towards the
multicast source to create an SPT. Because of the timeout of the (S, G) entry, the remote user
cannot receive the multicast data sent by S.
The S9300 supports the transmission of burst multicast data. You can enable the function of
encapsulating a multicast data packet in an SA message on the source RP. The source RP can
then encapsulate multicast data in an SA message and send the message out. After receiving the
SA message, the remote RP decapsulates the message, and then forwards multicast data to hosts
in the domain along the RPT.
Setting the TTL threshold can limit the transmission scope of a multicast data packet contained
in an SA message. After receiving an SA message containing a multicast data packet, an MSDP
peer checks the TTL value in the IP header of the multicast packet. If the TTL value is equal to
or smaller than the threshold, the MSDP peer does not forward the SA message to the specific

remote peers. If the TTL value is greater than the threshold, the MSDP peer reduces the TTL
value in the IP header of the multicast packet by 1, and then encapsulates the multicast packet
in an SA message and sends the message out.
Rules for Creating, Receiving, and Forwarding SA Messages

By default, MSDP switchs receive all SA messages that pass the RPF check and forward them
to all MSDP peers.
To control the transmission of SA messages between MSDP peers, you can configure filtering
rules by using the following methods:
l Setting rules for filtering SA messages based on multicast sources on the source RP
The source RP filters active multicast sources that register with the local switch, and then
determines whether to send (S, G) entries based on the rules.
l Setting rules for filtering SA messages received from remote MSDP peers
When an SA message sent by a remote MSDP peer reaches the local switch, the switch
determines whether to receive the message based on the rules.
l Setting rules for filtering SA messages forwarded to remote MSDP peers
Before forwarding an SA message to a remote MSDP peer, the local switch determines
whether to forward it based on the rules.
Multi-Instance MSDP
MSDP peer relationships can be set up between interfaces on multicast switchs that belong to
the same instance (including the public instance and VPN instance). MSDP peers exchange SA
message with each other. The inter-domain VPN multicast is thus implemented.
Multicast switchs on which multi-instance is applied maintain a set of MSDP mechanisms for
each instance. Multicast switchs also guarantee the information separation among different
instances; therefore, only MSDP and PIM-SM that belong to the same instance can interact.
By applying multi-instance, the S9300 implements inter-domain VPN multicast.
NOTE
For details of inter-domain VPN multicast, refer to the chapter Multicast VPN Configuration.
MSDP Authentication
Configuring MSDP MD5 or Key-Chain authentication can improve the security of TCP
connections set up between MSDP peers. Note that the MSDP peers must be configured with
the same authentication password; otherwise, the TCP connection cannot be set up between
MSDP peers and MSDP messages cannot be transmitted.
7.3 Configuring PIM-SM Inter-domain Multicast

This section describes how to set up an MSDP peer relationship between PIM-SM domains in
an AS and how to configure MSDP peers.

Before configuring PIM-SM inter-domain multicast, you need to configure intra-domain
multicast.

When a large multicast network is divided into multiple PIM-SM domains, MSDP is used to
connect RPs of various domains to share the source information. In this manner, hosts in a domain
can receive multicast data sent by multicast sources in other domains.
To ensure that all RPs in the network can share the source information, reduce the scale of an
MSDP connected graph. It is recommended to configure MSDP peer relationships between all
RPs, including static RPs and C-RPs, in the network.
To ensure that SA messages transmitted between MSDP peers are not interrupted by RPF rules
and to reduce redundant traffic, the following solutions are recommended:
l Add MSDP peers in the same AS to one Mesh Group.
l If MSDP peers are in different ASs, select either of the following solutions:
– Establish an MBGP peer relationship and use the same interface address.
– Configure each other as a static RPF peer.
NOTE
Both BGP and MBGP can be used to set up inter-AS EBGP peer relationships. MBGP is recommended
because MBGP does not affect the unicast topology of a network.
Before configuring PIM-SM inter-domain multicast, complete the following tasks:
l Configuring a unicast routing protocol to enable interworking at the network layer
l Enabling IP multicast
l Configuring a PIM-SM domain to implement intra-domain multicast
Data Preparation
To configure PIM-SM inter-domain multicast, you need the following data.
No. Data
1 Address of a remote MSDP peer
2 Type and number of the local interface connected to MSDP peers
3 Description of an MSDP peer
4 Name of a mesh group
7.3.2 Configuring Intra-AS MSDP Peers

When multiple PIM-SM domains exist in an AS or multiple RPs serving different multicast
groups exist in a PIM-SM domain, you are recommended to configure MSDP peer relationships
between all RPs (including static RPs and C-RPs) and add all MSDP peers to a mesh group.
Context
Do as follows on the RPs of all PIM-SM domains that belong to the same AS:

Procedure
Step 1 Run:
system-view
The system is displayed.
Step 2 Run:
msdp [ vpn-instance vpn-instance-name ]
MSDP is enabled in the public network instance or VPN instances and the MSDP view is
displayed.
Step 3 Run:
peer peer-address connect-interface interface-type interface-number
An MSDP peer connection is configured
The parameters of the command are explained as follows:
l peer-address: specifies the address of a remote MSDP peer.

l interface-type interface-number: specifies the local interface connected to the remote MSDP
peer.
NOTE
The system does not advertise routes on MTIs to VPNs; therefore, it is not allowed to use MTIs to set up
an MSDP peer connection.

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 with
the remote MSDP peers.
l peer-address specifies the address of a remote MSDP peer.

l text: specifies the description text. The text is a string of 80 characters.
Step 5 Run:
peer peer-address mesh-group name
A remote MSDP peer is configured to join a mesh group.
That is, the remote MSDP peer is acknowledged as a member of the mesh group.
The parameters of this command are explained as follows:

l name: specifies the name of a mesh group. The members of the same mesh group use the
same mesh group name.
Note the following:
l MSDP peer connections must be set up between all members of the same mesh group.
l All members of the mesh group must acknowledge each other as a member of the group.

l An MSDP peer can belong to only one mesh group. If an MSDP peer is configured to join
different mesh groups for multiple times, only the latest configuration is valid.
----End
7.3.3 Configuring Inter-AS MSDP Peers on MBGP Peers

You can configure an MSDP peer relationship between RPs in different ASs that have set up an
MBGP peer relationship. In this manner, PIM-SM domains in different ASs can share multicast
source information.
Context
Establish the MBGP peer relationship between two RPs of different ASs and do as follows on
the MBGP peers:
NOTE
If the two RPs set up the BGP peer relationship, it is not necessary to set up the MBGP peer relationship
between them.
Procedure
Step 1 Run:
system-view
Step 2 Run:
MSDP is enabled in the public network instance or VPN instance, and the MSDP view is
displayed.
Step 3 Run:
An MSDP peer connection is configured.
l peer-address: specifies the address of a remote MSDP peer. The address is the same as that
of the remote BGP or MBGP peer.
peer. The interface is the same as the local BGP or MBGP interface.

The description of the MSDP peer is added.
The configuration helps to distinguish the remote MSDP peers and manage the connections with

----End
7.3.4 Configuring Static RPF Peers

You can configure a static RPF peer relationship between RPs in different ASs so that PIM-SM
domains in different ASs can share multicast source information.
Context
NOTE
If Configuring Inter-AS MSDP Peers on MBGP Peers is complete, skip the configuration.
Do as follows on two RPs of different ASs:
Procedure
Step 1 Run:
system-view
Step 2 Run:
MSDP is enabled in the public network instance or VPN instance, and the MSDP view is
displayed.
Step 3 Run:
An MSDP peer connection is configured.

peer.

The description of a remote MSDP peer is added.
The configuration helps to distinguish remote MSDP peers and manage the connections with

l text: specifies the description text. The text is a string of up to 80 characters.
Step 5 Run:
static-rpf-peer peer-address [ rp-policy ip-prefix-name ]
A remote MSDP peer is statically specified as an RPF peer.

peer-address specifies the address of a remote MSDP peer.
----End

After PIM-SM inter-domain multicast is configured, you can run related commands to check
brief and detailed information about MSDP peers.
Procedure
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] brief command
to check the brief information about the statuses of all remote peers that establish MSDP
peer relationships with the local host.
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] peer-status
[ peer-address ] to check the detailed information about the statuses of the specified remote
peers that establish the MSDP peer relationships with the local host.
----End
Example
<Quidway> display msdp brief
MSDP Peer Brief Information of VPN-Instance: public net
Configured Up Listen Connect Shutdown Down
2 2 0 0 0 0
Peer's Address State Up/Down time AS SA Count Reset Count

192.168.2.1 UP 01:07:08 200 8 0
192.168.4.2 UP 00:06:39 100 13 0
Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] brief command. If the
brief information about the remote MSDP peer status is displayed, it means that the configuration
succeeds. For example:
2 2 0 0 0 0

192.168.2.1 UP 01:07:08 200 8 0
192.168.4.2 UP 00:06:39 100 13 0
Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] peer-status [ peer-

address ] command. If the verborse information about the remote MSDP peer status is displayed,
it means that the configuration succeeds. For example:
[Quidway] display msdp peer-status 10.110.11.11
display msdp peer-status 10.110.11.11
MSDP Peer Information of VPN-Instance: public net
MSDP Peer 20.20.20.20, AS 100
Description:
Information about connection status:
State: Up
Up/down time: 14:41:08
Resets: 0
Connection interface: LoopBack0 (20.20.20.30)
Number of sent/received messages: 867/947
Number of discarded output messages: 0
Elapsed time since last connection or counters clear: 14:42:40
Information about (Source, Group)-based SA filtering policy:
Import policy: none
Export policy: none
Information about SA-Requests:

Policy to accept SA-Request messages: none

Sending SA-Requests status: disable
Minimum TTL to forward SA with encapsulated data: 0
SAs learned from this peer: 0, SA-cache maximum for the peer: none
Input queue size: 0, Output queue size: 0
Counters for MSDP message:
Count of RPF check failure: 0
Incoming/outgoing SA messages: 0/0
Incoming/outgoing SA requests: 0/0
Incoming/outgoing SA responses: 0/0
Incoming/outgoing data packets: 0/0 Peer authentication: configured
Peer authentication type: KeyChain
7.4 Configuring an Anycast RP in a PIM-SM Domain

Anycast RP indicates that when multiple RPs with the same address reside in the same PIM-SM
domain and MSDP peer relationships are set up between these RPs, IP routing automatically
selects the topologically closest RP for each source and receiver. In this manner, burdens on a
single RP are released, RP backup is implemented, and the forwarding path is optimized.

You can configure anycast RP in the scenario where devices in a PIM-SM domain are reachable,
PIM-SM is enabled on the interfaces configured with multicast routing, and no RP is configured
in the network.
In a traditional PIM-SM domain, each multicast group can be mapped to only one RP. When
the network is overloaded or the traffic is too concentrated, many network problems are caused.
For example, the pressure of the RP is too heavy, switchs converge slowly after the RP fails,
and the multicast forwarding path is not optimal.
After anycast RPs are applied in a PIM-SM domain, the source registers with the nearest RP and
hosts sends Join messages to the nearest RP. That is, the load of a single RP is abated, the RP
backup is implemented, and the forwarding path is optimized.
The recommended configuration solutions are as follows:
l Configure loopback interfaces on multiple switchs in the PIM-SM domain respectively,
assign the same IP address to the loopback interfaces, and advertise the IP address by using
unicast routes.
l Configure the loopback interfaces on the switchs as C-RPs or configure the address of the
loopback interface as a static RP on all switchs in the PIM-SM domain.
l Set up the MSDP peer relationship between the switchs. If the number of switchs is greater
than three, it is recommended to set up the MSDP peer relationship between the switchs
and configure them to join the same mesh group.
l Specify the logical RP address to transmit SA messages between the MSDP peers.
Before configuring an anycast RP in a PIM-SM domain, complete the following tasks:
l Configuring a unicast routing protocol to implement interconnection at the network layer

l Configuring a PIM-SM domain without any RP
Data Preparation
To configure an anycast RP in a PIM-SM domain, you need the following data.
No. Data
1 RP address
2 Interface and address of the local MSDP peer
3 Interface and address of the remote MSDP peer
4 Description of an MSDP peer
7.4.2 Configuring the Interface Address of an RP

Before configuring anycast on the devices in a PIM-SM domain, configure a loopback interface
on each device and assign the same IP address to the loopback interfaces. In addition, advertise
the IP address of the RP through unicast routes to ensure that each device has a reachable route
to the RP interface.
Context
Use a unicast routing protocol in the current network to advertise the address of the newly
configured RP interface. Ensure that all switchs in the network have a route to the RP.
In the PIM-SM domain, do as follows on multiple switchs on which the anycast RP is to be
configured:
Procedure
Step 1 Run:
system-view

Step 2 Run:
interface loopback interface-number
The loopback interface view is displayed.

Multiple RPs can use the same IP address in a network. The RPs, therefore, are configured on
the loopback interface.
Step 3 Run:
ip address ip-address { mask | mask-length }
The address of the loopback interface is configured.

l ip-address: specifies the address of an RP. The RPs configured on multiple devices uses the
same IP address.

l mask | mask-length: specifies the address mask of the loopback interface.

Step 4 Run:
pim sm
PIM-SM is enabled for the RP interface.
NOTE
Before configuring a dynamic RP, you need to run this command. This command is not required when you
configure a static RP.
----End
7.4.3 Configuring a C-RP

A loopback interface is generally configured as a C-RP on the device to be configured with
anycast RP.
Context
NOTE
l If the PIM-SM network uses a static RP, the configuration is not necessary.
l If the PIM-SM network uses a BSR-RP, the configuration is mandatory. Before configuring a C-RP,
configure a BSR and BSP boundary. The BSR address cannot be the same as the C-RP address.
Do as follows on multiple switchs where anycast RP is to be configured in the PIM-SM domain:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
c-rp loopback interface-number
An interface is configured as a C-RP.
----End
7.4.4 Statically Configuring an RP

To configure a static RP, you need to configure the addresses of the loopback interfaces as the
RP addresses on all the devices in a PIM-SM domain.
Context
NOTE
l When the PIM-SM network uses a BSR-RP, the configuration is not necessary.
l When the PIM-SM network uses a static RP, the configuration is mandatory.

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
static-rp rp-address
The loopback interface address is configured as a static RP address.
----End
7.4.5 Configuring an MSDP Peer

MSDP peer relationships need be set up between RPs. If there are more than three devices,
MSDP peer relationships should be set up between any two devices and all MSDP peers should
be added to one mesh group.
Context
Do as follows on multiple switchs on which an anycast RP is to be created:
NOTE
If the number of switchs configured with the RPs that have the same IP address exceeds two, ensure the
interconnection between the switchs that set up MSDP peer relationship.
Procedure
Step 1 Run:
system-view

Step 2 Run:
MSDP is enabled in the public network instance or the VPN instance, and the MSDP view is
displayed.
Step 3 Run:
An MSDP peer connection is created.

l interface-type interface-number: specifies the local interface.


The description of the MSDP peer is added.

This configuration helps to differentiate remote MSDP peers and manage the connection with
peer peer-address mesh-group name
A remote MSDP peer is configured to join a mesh group.

That is, the remote MSDP peer is acknowledged as a member of the mesh group.
If only two switchs are configured with the anycast-RP, this configuration is not necessary.
l name: specifies the name of a mesh group. The members of the same mesh group use the
same mesh group name.
Note the following:
l MSDP peer connections must be set up between all members of the mesh group.
l All members of the mesh group must acknowledge each other as the member of the mesh
group.
l An MSDP peer belongs to only one mesh group. If an MSDP peer is configured to join
different mesh groups for many times, only the last configuration is valid.
----End
7.4.6 Specifying the Logical RP Address for an SA Message

After receiving an SA message, an MSDP peer performs the RPF check on the message. If the
remote RP address carried in the SA message is the same as the local RP address, the MSDP
peer discards the SA message. Therefore, you need to specify a logical RP address for SA
messages on the device on which anycast RP is to be configured.
Context
After receiving an SA message, an MSDP peer performs the RPF check on the message. If the
remote RP address carried in the SA message is the same as the local RP address, the SA message
is discarded.
Do as follows on the switchs on which the anycast RP is to be configured:
Procedure
Step 1 Run:
system-view


Step 2 Run:
The MSDP view is displayed.

Step 3 Run:
originating-rp interface-type interface-number
The logical RP interface is configured. The logical RP interface cannot be the same as the actual
RP interface. It is recommended to configure the logical interface as the MSDP peer interface.
After the originating-rp command is used, the logical RP address carried in the SA message
sent by the switch replaces the RP address in the IP header of the SA message, and the SA
message can pass the RPF check after reaching the remote switch.
NOTE
The system does not advertise routes on the MTIs to VPNs; therefore, the MTIs cannot be used as logical
RPs.
----End

After anycast RP in a PIM-SM domain is configured, you can run related commands to check
brief and detailed information about MSDP peers and RP information of PIM routing entries.
Procedure
to check the brief information of the MSDP peer status.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] routing-table
command to check the information about the RP corresponding to the PIM routing table.
----End
Example
Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] brief command. If the
brief information about the remote MSDP peer status is displayed, it means that the configuration
succeeds. For example:
1 1 0 0 0 0

2.2.2.2 UP 00:10:17 ? 0 0
Run the display pim [ vpn-instance vpn-instance-name | all-instance ] routing-table

command. If the RP information corresponding to the routing table is displayed, it means that
the configuration succeeds. For example:
<Quidway> display pim routing-table
(10.11.1.2, 225.1.1.1)
RP: 7.7.7.7 (local)

UpTime: 00:01:57
1: Vlanif20
Protocol: pim-sm, UpTime: - , Expires: -
7.5 Managing MSDP Peer Connections

MSDP peers should set up TCP connections. You can then flexibly control the sessions set up
between MSDP peers by closing or re-establishing TCP connections. You can also adjust the
interval for retrying to set up a TCP connection between MSDP peers.

After PIM-SM inter-domain multicast or anycast RP in a PIM-SM domain is configured, you
can manage the connection between MSDP peers as required.
MSDP peers are connected by the TCP connection (the port number is 639). Users can close or
reestablish a TCP connection, and flexibly control the sessions set up between MSDP peers.
When a new MSDP peer is created, or when a closed MSDP peer connection is restarted, or
when a faulty MSDP peer tries recovering, the TCP connection needs to be immediately set up
between MSDP peers. Users can flexibly adjust the interval for retrying setting up an MSDP
peer connection.
Before managing MSDP peer connections, complete the following tasks:

l Configuring PIM-SM Inter-domain Multicast or Configuring an Anycast RP in a
PIM-SM Domain
Data Preparation
To manage MSDP peer connections, you need the following data.
No. Data
2 Interface type and interface number of the local switch

7.5.2 Controlling the Sessions Between MSDP Peers

After the connection between MSDP peers is closed, the MSDP peers no longer exchange SA
messages and do not retry to set up a new connection. You can restart the connection between
the MSDP peers as required.
Context
Do as follows on the switch on which the MSDP peer is created:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
shutdown peer-address
A session with the remote MSDP peer is closed.

l After the session with the remote MSDP peer is closed, the TCP connection is closed, the
peers no longer transmit SA messages, and the peers do not re-try setting up the connection.
The configuration, however, is saved.
l You can run the undo shutdown peer-address command to open the session with the remote
MSDP peer, and reestablish the TCP connection.
----End
7.5.3 Adjusting the interval for Retrying Setting up an MSDP Peer

Connection
When a new MSDP peer relationship is created, when a closed MSDP peer connection is
restarted, or when a faulty MSDP peer tries recovering, a TCP connection needs to be
immediately set up between the MSDP peers. You can flexibly adjust the interval for retrying
to set up a TCP connection between MSDP peers.
Context
Do as follows on the switch on which the MSDP peer is created:
Procedure
Step 1 Run:
system-view


Step 2 Run:

Step 3 Run:
timer retry interval
The period for retrying sending the TCP connection request to the remote MSDP peer is set
----End

After a TCP connection is set up between MSDP peers, you can run related commands to check
brief and detailed information about MSDP peers.
Procedure
to check the brief information about the statuses of all remote peers that establish MSDP
peer relationships with the local host.
[ peer-address ] to check the detailed information about the statuses of the specified remote
peers that establish the MSDP peer relationships with the local host.
----End
Example
2 2 0 0 0 0

192.168.2.1 UP 01:07:08 200 8 0
192.168.4.2 UP 00:06:39 100 13 0
7.6 Configuring SA Cache

An SA cache is used to save the (S, G) information carried in SA messages locally. When a
device needs to receive multicast data, it directly obtains available (S, G) information from the
SA cache.

can configure an SA cache as required.
By default, SA Cache is enabled on switchs on which MSDP peers are configured. The
switchs can locally store the (S, G) information carried in SA messages. When the switchs need
to receive (S, G) information, the switchs can obtain the (S, G) information from the SA Cache.

Setting the maximum number of (S, G) entries can prevent the Denial of Service (DoS) attack.
Users can disable the SA Cache of a switch. After the SA Cache of a switch is disabled, the
switch does not locally store the (S, G) information carried in SA messages. When a switch
wants to receive (S, G) data, it needs to waits for the SA message to be sent by its MSDP peer
in the next period. This delays receivers from obtaining multicast data.
Before configuring SA Cache, complete the following tasks:
PIM-SM Domain
Data Preparation
To configure SA Cache, you need the following data.
No. Data
1 Maximum number of (S, G) entries in the SA Cache
7.6.2 Configuring the Maximum Number of (S, G) Entries in the

Cache
Setting the maximum number of (S, G) entries in an SA cache can prevent DoS attacks.
Context
Do as follows on the switch on which the MSDP peer is configured:
NOTE
If the configuration is not done, default values are used.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
peer peer-address sa-cache-maximum sa-limit

The maximum number of (S, G) entries is set.

l sa-limit: specifies the maximum number of cached (S, G) entries. The value of configuration
is valid when it is less than the specification of cache. Contrarily, specification of cache is
valid.
----End
7.6.3 Disabling the SA Cache Function

You are allowed to disable the SA cache function. Then, when a device wants to receive multicast
data, it needs to wait for the SA message to be sent by its MSDP peer in the next period. This
results in a delay in obtaining multicast data.
Context
Do as follows on the switch on which the MSDP peer is configured:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
undo cache-sa-enable
The SA Cache function is disabled.
NOTE
To reenable SA Cache, run the cache-sa-enable command in the MSDP view.
----End

After the SA cache function is configured, you can run related commands to check brief 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 | [ 2-byte-as-number | 4-byte-as-number ] ] * command to check
(S, G) entries in the SA Cache of the public network instance, VPN instance or all instances.

l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] sa-count [ 2-

byte-as-number | 4-byte-as-number ] command to check the number of (S, G) entries in the
SA Cache of the public network instance, VPN instance or all instances.
----End
Example
Run the display msdp sa-cache command to check (S, G) entries in SA Cache.
<Quidway> display msdp sa-cache
MSDP Source-Active Cache Information of VPN-Instance: public net
MSDP Total Source-Active Cache - 3 entries
MSDP matched 3 entries
(8.8.8.8, 225.0.0.200)
Origin RP: 4.4.4.4
Pro: BGP, AS: 10
Uptime: 00:00:33, Expires: 00:05:27
(8.8.8.8, 225.0.0.201)
Origin RP: 4.4.4.4
Pro: BGP, AS: 1.0
Uptime: 00:00:33, Expires: 00:05:27
(8.8.8.8, 225.0.0.202)
Origin RP: 4.4.4.4
Pro: BGP, AS: 65535.65535
Uptime: 00:00:33, Expires: 00:05:27
Run the display msdp sa-count command to check the number of (S, G) entries in SA Cache.
<Quidway> display msdp sa-count
MSDP Source-Active Count Information of VPN-Instance: public net
Number of cached Source-Active entries, counted by Peer
Peer's Address Number of SA
10.10.10.10 5
Number of source and group, counted by AS
AS Number of source Number of group
? 3 3
Total 5 Source-Active entries matched
7.7 Configuring the SA Request

If the capacity of the SA cache enabled on the remote MSDP peer is too large, configuring
"sending SA Request message" on the local device can shorten the time taken by a receiver to
obtain multicast source information. You can configure filtering rules for receiving SA Request
messages on a specified remote MSDP peer.

can configure "SA Request message sending" as required.
The capacity of SA Cache on certain switchs is small. When these switchs need to receive
multicast data, they cannot immediately obtain the valid (S, G) information and need to wait for
the SA message sent by their MSDP peers in the next period.
If SA Cache is enabled on the remote MSDP peer and the capacity of the SA Cache is large,
configuring "sending SA Request message" on the local switch can shorten the period during
which receivers obtain multicast source information.

l When the local switch wants to receive (S, G) information, it sends an SA Request message
to a specified remote MSDP peer.
l On receiving the SA Request message, the MSDP peer responds to the SA Request message
with the required (S, G) information. If the "filtering rule of SA Request message" is
configured on the remote MSDP peer, it checks the SA Request messages received from a
specified peers and determines whether to respond according to the checking results.
Before configuring an SA request, complete the following tasks:
PIM-SM Domain
Data Preparation
To configure an SA request, you need the following data.
No. Data
2 Filtering list for receiving SA request messages
7.7.2 Configuring "Sending SA Request Messages" on the Local

switch
When a device receives a new Join message and no corresponding (S, G) entry exists locally or
in the SA cache, the device immediately sends an SA Request message to the specified MSDP
peer rather than waits for the SA message in the next period.
Context
Do as follows on the local switch:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:

peer peer-address request-sa-enable
Sending SA Request message is configured.
peer-address specifies the address of a remote MSDP peer. When the local switch receives a
new Join message from a group, it sends an SA Request message only to peer-address.
----End
7.7.3 (Optional) Configuring the Filtering Rules for Receiving SA

Request Messages
You can configure rules for filter the SA Request messages received from the local device on a
specified remote MSDP peer. If the SA Request message passes the filtering, the peer
immediately responds.
Context
Do as follows on the remote MSDP peer specified by using the peer peer-address request-sa-
enable command. If the configuration is not done, once an SA message reaches, the switch
immediately responds to it with an SA message containing the required (S, G) information.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer peer-address sa-request-policy [ acl { basic-acl-number | acl-name } ]
The filtering rules for receiving SA Request messages are set.
l peer-address: specifies the address of an MSDP peer that sends the SA Request message.
l acl: specifies the filtering policy. If the ACL is not specified, all SA messages sent by a peer
are ignored. If the ACL is specified, only the SA messages that match the ACL are received
and other SA messages are discarded.
----End
7.7.4 Check the Configuration

After "SA Request message sending" is configured, you can run related commands to check
detailed information about MSDP peers and SA cache information.
Procedure
[ peer-address ] command to check detailed information about the MSDP peer status.


SA Cache of the public network instance, VPN instance, or all instances.
----End
Example
Run the display msdp peer-status [ peer-address ] command, and you can view the SA-
Requests field and check whether the configuration is valid. For example:
<Quidway> display msdp peer-status
MSDP Peer 172.40.41.1, AS ?
Description:
State: Up
Resets: 0
Connection interface: Vlanif10 (172.40.41.2)
Import policy: none
Export policy: none
Policy to accept SA-Request messages: 2000
Sending SA-Requests status: enable
SAs learned from this peer: 0, SA Cache maximum for the peer: none
Incoming/outgoing data packets: 0/0
Peer authentication: configured
Peer authentication type: Key-Chain
7.8 Transmitting Burst Multicast Data Between Domains

By default, an SA message carries only (S, G) information. Then, if burst multicast data need
be transmitted between domains, you can configure multicast data encapsulation for an SA
message on the source RP. In addition, you can set the TTL threshold to limit the transmission
scope of multicast data encapsulated in an SA message.

can configure the transmission of burst multicast data between domains as required.
The time during which certain multicast sources send multicast data is long, and is longer than
the timeout of an (S, G) entry. In this case, the source DR encapsulates multicast data packets
in Register messages one by one, and sends the messages to the source RP. The source RP then
uses SA messages to forward (S, G) entries to the remote RP.
The remote RP then sends a Join message to the source DR. An SPT is thus set up. Because of
the timeout of the (S, G) entry, remote users cannot receive multicast data sent by S.

After the function of encapsulating a multicast packet in an SA message is enabled on the source
RP, the source RP encapsulates multicast data in SA messages and sends them out. After
receiving an SA message, a remote RP decapsulates the message and forwards the multicast data
to users in the domain along the RPT.
Setting the TTL threshold can limit the transmission scope of a multicast packet contained in an
SA message. After receiving an SA message containing a multicast packet, an MSDP peer checks
the TTL value in the IP header of the multicast packet. If the TTL value is smaller than or equal
to the threshold, the MSDP peer does not forward the SA message to a specific remote peers. If
the TTL value is greater than the threshold, the MSDP peer reduces the TTL value in the IP
header of the multicast packet by 1, and then encapsulates the multicast packet in an SA message
and sends it out.
Before transmitting burst multicast data between domains, complete the following tasks:
PIM-SM Domain
Data Preparation
To transmit burst multicast data between domains, you need the following data.
No. Data
1 TTL threshold for forwarding an SA message containing a multicast data packet
7.8.2 Encapsulating a Multicast Data Packet in an SA message

By default, an SA message contains only (S, G) information, with no multicast data packets
encapsulated. You can configure multicast data encapsulation for an SA message on the source
RP configured with an MSDP peer.
Context
Do as follows on the source RP configured with an MSDP peer:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
encap-data-enable
A multicast data packet is encapsulated in an SA message.
By default, the SA message contains only (S, G) information, and does not contain a multicast
data packet.
----End
7.8.3 (Optional) Setting the TTL Threshold for Forwarding an SA

Message Containing a Multicast Data Packet
After receiving an SA massage encapsulated with a multicast data packet, an MSDP peer
forwards the SA message to a specified remote MSDP peer only when the TTL value of the
multicast packet is greater than the set threshold.
Context
Do as follows on the switch configured with an MSDP peer:
NOTE
If the configuration is not done, default values are used.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer peer-address minimum-ttl ttl
The TTL threshold of a multicast data packet is set.
After receiving an SA massage containing a multicast data packet, an MSDP peer forwards the
SA message to a specified remote MSDP peers only when the TTL value of the multicast packet
is greater than the threshold.

l ttl: specifies the value of the TTL threshold. By default, the value is 0.
----End


After the transmission of burst multicast data is configured, you can run related commands to
check detailed information about MSDP peers and SA cache information.
Procedure
----End
Example
Run the display msdp peer-status [ peer-address ] command, and you can view the minimum
TTL for forwarding an SA messages containing a data packet and check whether the
configuration is valid. For example:
MSDP Peer 172.40.41.1, AS ?
Description:
State: Up
Resets: 0
Import policy: none
Export policy: none
Peer authentication: unconfigured
Peer authentication type: none
Run the display msdp sa-cache command to check the information about (S, G) entries in SA
Cache.
l If group-address is specified, the (S, G) entry to which a specified group corresponds is
displayed.
l If source-address is specified, the (S, G) entry to which a specified source corresponds is
displayed.
l If 2-byte-as-number or 4-byte-as-number is specified, the (S, G) entry whose Origin RP
attribute belongs to a specified AS is displayed.


(8.8.8.8, 225.0.0.200)
Origin RP: 4.4.4.4
Pro: BGP, AS: 10
Uptime: 00:00:33, Expires: 00:05:27
(8.8.8.8, 225.0.0.201)
Origin RP: 4.4.4.4
Pro: BGP, AS: 1.0
Uptime: 00:00:33, Expires: 00:05:27
(8.8.8.8, 225.0.0.202)
Origin RP: 4.4.4.4
Pro: BGP, AS: 65535.65535
Uptime: 00:00:33, Expires: 00:05:27
7.9 Configuring the Filtering Rules for SA Messages

By default, a device receives all SA messages that pass the RPF check, and forwards the SA
messages to all MSDP peers. To control the transmission of SA messages among MSDP peers,
you can configure rules to filter the constructing, receiving, and forwarding SA messages.

can configure filtering rules for SA messages.
By default, MSDP switchs receive all SA messages that pass the RPF check and forward them
to all MSDP peers. To control of the transmission of SA messages among MSDP peers, users
can configure various filtering rules by using the following methods:
l Setting the rules for filtering the multicast source of an SA message on the source RP. The
source RP filters active multicast sources that register with the local switch, and determines
the (S, G) entries to be sent according to the rules.
l Setting the rules for filtering an SA message received from a remote MSDP peer. When an
SA message sent by a remote MSDP peer reaches a switch, the switch determines whether
to receive the message based on the rules.
l Setting the rules for filtering an SA message forwarded to a remote MSDP peer. Before
forwarding the SA message to the remote MSDP peer, the switch determines whether to
forward it based on the rules.
Before configuring the filtering rules for SA messages, complete the following tasks:

PIM-SM Domain

Data Preparation
To configure the filtering rules for SA messages, you need the following data.
No. Data
1 Filtering list for creating SA messages
2 Filtering list for receiving SA messages
3 Filtering list for forwarding SA messages
7.9.2 Setting Rules for Creating an SA Message

You can set rules for filtering the multicast source of an SA message on the source RP. The
source RP then filters locally registered and active multicast sources, and determines which (S,
G) information need be advertised based on the set rules.
Context
Do as follows on the source RP configured with an MSDP peer:
NOTE
If the configuration is not done, an SA message created by the source RP contains the information of all
local active sources.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
import-source [ acl { acl-number | acl-name } ]
The rules for filtering the multicast source of an SA message are set.
l acl: specifies the filtering list based on multicast sources. The SA message created by an
MSDP peer contains the local source information that match the filtering rules. The MSDP
peer can thus control the local (S, G) information.
l If the import-source command with acl is used, the SA message does not advertise any
information about the local active source.
----End

7.9.3 Setting Rules for Receiving an SA Message

You can set the rules for filtering the received SA messages on a specified remote MSDP peer.
When SA messages sent by a remote MSDP peer reach the local device, the local device
determines whether to accept the messages based on the set rules.
Context
Do as follows on the switch configured with MSDP:
NOTE
If the configuration is not done, the switch receives all SA messages that pass the RPF check.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer peer-address sa-policy import [ acl { advanced-acl-number | acl-name } ]
The rules for filtering an SA message received from a remote MSDP peer are set.

l acl: specifies the advanced filtering list. Only the (S, G) information that passes the filtering
of the ACL is received. The (S, G) information is contained in an SA message sent by the
peer specified by peer-address .
l If the peer peer-address sa-policy import command without acl is used, the switch does not
receive any (S, G) information from the peer specified by peer-address.
----End
7.9.4 Setting Rules for Forwarding an SA Message

You can set the rules for filtering the SA messages to be forwarded to a remote MSDP peer on
a local device. The local device then determines whether to forward the received SA messages
based on the set rules.
Context
Do as follows on the switch enabled with MSDP:
NOTE
If the configuration is not done, the switch forwards all SA messages that pass the RPF check.

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
peer peer-address sa-policy export [ acl advanced-acl-number ]
The rules for filtering an SA message forwarded to a remote MSDP peer is set.
l acl: specifies the advanced filtering list. Only the (S, G) information that matches the ACL
rule is forwarded to the peer specified by peer-address.
l If the peer peer-address sa-policy export command without acl is used, the switch does not
forward any (S, G) information to the peer specified by peer-address.
----End

After filtering rules for SA messages are configured, you can run related commands to check
detailed information about MSDP peers and SA cache information.
Procedure
----End
Example
Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] peer-status [ peer-
address ] command, and you can view information about the (Source, Group)-based SA filtering
policy field and check whether the configuration is valid. For example:
MSDP Peer 172.40.41.1, AS ?
Description:
State: Up
Resets: 0


Import policy: 3000
Export policy: 3002
Run the display msdp sa-cache command to check the information about (S, G) entries in SA
Cache.
l If group-address is specified, the (S, G) entry to which a specified group corresponds is
displayed.
l If source-address is specified, the (S, G) entry to which a specified source corresponds is
displayed.
l If 2-byte-as-number or 4-byte-as-number is specified, the (S, G) entry whose Origin RP
attribute belongs to a specified AS is displayed.
(8.8.8.8, 225.0.0.200)
Origin RP: 4.4.4.4
Pro: BGP, AS: 10
Uptime: 00:00:33, Expires: 00:05:27
(8.8.8.8, 225.0.0.201)
Origin RP: 4.4.4.4
Pro: BGP, AS: 1.0
Uptime: 00:00:33, Expires: 00:05:27
(8.8.8.8, 225.0.0.202)
Origin RP: 4.4.4.4
Pro: BGP, AS: 65535.65535
Uptime: 00:00:33, Expires: 00:05:27
7.10 Configuring MSDP Authentication

MSDP peer authentication contains MSDP MD5 authentication and Key-Chain authentication.
You can choose either authentication mode.

After Anycast RP is configured for PIM-SM intra-domain or inter-domain multicast, you can
configure MSDP authentication as required to ensure the security of the TCP connection between
MSDP peers.
Configuring MSDP authentication can enhance the security of the TCP connections between
MSDP peers.

Before configuring MSDP authentication, complete the following tasks:
l Configuring a unicast routing protocol to implement IP interworking between domains

l Configuring PIM-SM domains to implement intra-domain multicast
PIM-SM Domain
Data Preparation
Before configuring MSDP authentication, prepare the following data:
No. Data
1 IP address of the peer to be configured with MSDP authentication
2 Password for MSDP MD5 authentication
3 Key-Chain name for MSDP Key-Chain authentication
7.10.2 Configuring MSDP MD5 Authentication

The MSDP peers must be configured with the same authentication password; otherwise, the TCP
connection cannot be set up between MSDP peers and MSDP messages cannot be transmitted.
The authentication password on peers can be in different forms, that is, the password on one end
can be in the cipher text while the password on the peer can be in the plain text.
Context
By default, MSDP MD5 authentication is not configured.
Do as follows on the switch configured with MSDP peers:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
peer peer-address password { cipher cipher-password | simple simple-password }
MSDP MD5 authentication is configured.

The MSDP MD5 authentication password is case sensitive and cannot contain any space.

The MSDP peers must be configured with the same authentication password; otherwise, the TCP
connection cannot be set up between MSDP peers and MSDP messages cannot be transmitted.
The authentication password on peers can be in different forms, that is, the password on one end
can be in the cipher text while the password on the peer can be in the plain text.
NOTE
MSDP MD5 authentication and MSDP Key-Chain authentication are mutually exclusive.
Characters $@$@ are used as the prefix and suffix of passwords with variable lengths, and they cannot be
both configured at the beginning and end of a plain text password.
----End
7.10.3 Configuring MSDP Key-Chain Authentication

You must configure Key-Chain authentication on both MSDP peers. Encryption algorithms and
passwords configured for Key-Chain authentication on both peers must be the same; otherwise,
the TCP connection cannot be set up between MSDP peers and MSDP messages cannot be
transmitted.
Context
By default, MSDP Key-Chain authentication is not configured.
Do as follows on the switch configured with MSDP peers:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer peer-address keychain keychain-name
MSDP Key-Chain authentication is configured.
You must configure Key-Chain authentication on both MSDP peers. Encryption algorithms and
passwords configured for Key-Chain authentication on both peers must be the same; otherwise,
the TCP connection cannot be set up between MSDP peers and MSDP messages cannot be
transmitted.
Before configuring MSDP Key-Chain authentication, configure a Key-Chain in accordance with

the configured keychain-name; otherwise, the TCP connection cannot be set up.
NOTE
MSDP MD5 authentication and MSDP Key-Chain authentication are mutually exclusive.
----End


After MSDP authentication is configured, you can run related commands to check brief and
detailed information about MSDP peers.
Procedure
to check brief information about MSDP peers.
[ peer-address ] command to check detailed information about MSDP peers.
----End
Example
Run the display msdp peer-status [ peer-address ] command, and you can find the Peer
authentication and Peer authentication type fields in the command output. For example:
MSDP Peer 172.40.41.1, AS ?
Description:
State: Up
Resets: 0
Import policy: 3000
Export policy: 3002
Peer authentication: configured
Peer authentication type: KeyChain
7.11 Maintaining MSDP

Maintaining MSDP involves clearing MSDP peer statistics and (S, G) information in the SA
cache, and monitoring MSDP running status.
7.11.1 Clearing Statistics of MSDP Peers

When clear MSDP peer statistics, you can choose whether to reset the TCP connection between
MSDP peers. Note that MSDP peer statistics cannot be restored after you clear them. Resetting
the TCP connection will affect the running of MSDP.

Context
CAUTION
The statistics of MSDP peers cannot be restored after you clear it. So, confirm the action before
you use the command.
Procedure
l Run the reset msdp [ vpn-instance vpn-instance-name | all-instance ] peer [ peer-
address ] command in the user view to clear the TCP connection with a specified MSDP
peer and 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 an MSDP peer or multiple
MSDP peers of the public network instance, VPN instance, or all instances, if MSDP peers
are not reset.
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 about the
received, sent, and discarded MSDP messages.
----End
7.11.2 Clearing (S, G) Information in SA Cache

When you want to reset contents in an SA cache, you can clear all (S, G) information from the
SA cache. Note that the (S, G) information cannot be restored after you clear it.
Context
CAUTION
The (S, G) information in SA Cache cannot be restored after you clear it. So, confirm the action
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 entries in MSDP SA Cache.
----End
7.11.3 Monitoring the Running Status of MSDP

running of MSDP.

Context
status of MSDP.
Procedure
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] brief [ state
{ connect | down | listen | shutdown | up } ] command in any view to check brief
information about the MSDP peer status.
[ peer-address ] command in any view to check detailed information about the status of an
MSDP peer of the public network instance, VPN instance, or all instances.
address | source-address | { 2-byte-as-number | 4-byte-as-number } ] * command in any
view to check the (S, G) information in SA Cache.
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] sa-count [ 2-
byte-as-number | 4-byte-as-number ] command in any view to check the number of (S, G)
entries in MSDP 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 in any view to check statistics about the received,
sent, and discarded MSDP messages.
----End
7.11.4 Debugging MSDP

When a fault occurs during the running of MSDP, run the debugging commands in the user view
Context
CAUTION
Debugging affects the performance of the system. So, after debugging, execute the undo
debugging all command to disable it immediately.
When an MSDP fault occurs, run the following debugging commands in the user view to debug
MSDP and locate the fault.
Procedure
l Run the debugging msdp [ vpn-instance vpn-instance-name | all-instance ] all command
in the user view to enable all the debugging of MSDP.
l Run the debugging msdp [ vpn-instance vpn-instance-name | all-instance ] connect
command in the user view to enable the debugging of the resetting of the MSDP peer
connection.

l Run the debugging msdp [ vpn-instance vpn-instance-name | all-instance ] event

command in the user view to enable the debugging of MSDP events.
l Run the debugging msdp [ vpn-instance vpn-instance-name | all-instance ] packet
command in the user view to enable the debugging of MSDP packets.
l Run the debugging msdp [ vpn-instance vpn-instance-name | all-instance ] source-
active command in the user view to enable the debugging of MSDP active sources.
----End

Configuration examples are provided to show how to implement PIM-SM inter-domain
multicast through MBGP, how to implement inter-AS multicast through static RPF peers, and
how to configure anycast RP in a PIM-SM domain.
7.12.1 Example for Configuring Basic MSDP Functions
As shown in Figure 7-1, two ASs exist on the network. Each AS contains one or more PIM-SM
domains; each PIM-SM domain has 0 or 1 multicast source and receiver. The receivers in PIM-
SM2 need to receive the multicast data sent by S3 in the PIM-SM3 domain and multicast data
sent by S1 in the PIM-SM1 domain.

Figure 7-1 Networking diagram for configuring basic MSDP functions
AS100 AS200
Loopback0 Receiver
Loopback0 2.2.2.2/32
1.1.1.1/32
PIM-SM2
SwitchA SwitchC GE1/0/0
GE2/0/0 GE1/0/0 GE1/0/0 GE2/0/0
GE2/0/0 GE2/0/0
GE1/0/0 SwitchB GE3/0/0 SwitchD
PIM-SM1
SwitchF
S1 GE3/0/0
GE2/0/0
GE2/0/0
GE1/0/0
SwitchE
PIM-SM3
S3
Loopback0
3.3.3.3/32
MSDP peer

GE 2/0/0 VLANIF 100 192.168.1.1/24
GE 2/0/0 VLANIF 100 192.168.1.2/24
GE 2/0/0 VLANIF 300 192.168.3.1/24
GE 3/0/0 VLANIF 400 192.168.4.1/24
GE 2/0/0 VLANIF 300 192.168.3.2/24
GE 3/0/0 VLANIF 400 192.168.4.2/24
SwitchF GE 1/0/0 VLANIF 103 10.110.3.1/24
GE 2/0/0 VLANIF 500 192.168.5.2/24
1. Configure the IP addresses of the interfaces on each Switch and configure OSPF in the AS
to ensure that the unicast routes within the AS are reachable.
2. Configure EBGP peers and import BGP and OSPF routes into each other's routing table to
ensure that the unicast routes between ASs are reachable.

3. Enable multicast and PIM-SM on each interface, configure the boundary domain, and
enable the IGMP function on the interfaces connected to hosts.
4. Configure the C-BSR and C-RP. Configure the RPs of PIM-SM1 and PIM-SM2 on the
ASBR.
5. Establish MSDP peer relationship between RPs of each domain. The MSDP peers and the
EBGP peers between ASs use the same interface addresses. According to the RPF rule, the
Switches receive SA messages from the next hop toward the source RP.
Data Preparation
l Number of the AS that SwitchA and SwitchB belong to, namely 100, and router ID of
SwitchB, namely, 1.1.1.1
l Number of the AS that SwitchC and SwitchD belong to, namely 200, and Router ID of
SwitchC, namely, 2.2.2.2
l Number of the AS that SwitchE and SwitchF belong to, namely 200
NOTE
This configuration example describes only the commands related to MSDP configuration.
Procedure
Step 1 Configure the IP addresses of interfaces and the unicast routing protocol.
# According to Figure 7-1, configure IP addresses and masks for the interfaces on each
Switch. Configure the OSPF protocol between Switches. Ensure the communication on the
network layer within an AS. Ensure the dynamic route update between Switches through unicast
routing protocol. The configuration procedure is not provided here.
Step 2 Configure EBGP peer relationship between ASs and import routes of BGP and OSPF into each
other's routing table.
# Configure EBGP on SwitchB and import OSPF routes.
[SwitchB] bgp 100
[SwitchB-bgp] router-id 1.1.1.1
[SwitchB-bgp] peer 192.168.2.2 as-number 200
[SwitchB-bgp] import-route ospf 1
[SwitchB-bgp] quit
# Configure EBGP on SwitchC and import OSPF routes.

[SwitchC] bgp 200
[SwitchC-bgp] router-id 2.2.2.2
[SwitchC-bgp] peer 192.168.2.1 as-number 100
[SwitchC-bgp] import-route ospf 1
[SwitchC-bgp] quit
# Import BGP routes to OSPF on SwitchB. The configuration on SwitchC is similar to the
configuration on SwitchB, and is not provided here.
[SwitchB] ospf 1
[SwitchB-ospf-1] import-route bgp
[SwitchB-ospf-1] quit
Step 3 Enable multicast, enable PIM-SM on all interfaces, configure the domain boundary, and enable
IGMP on the interface connecting to the host.

# Enable multicast on SwitchB and enable PIM-SM on each interface. The configurations of
other Switches are similar to the configuration of SwitchB, and are not provided here.
[SwitchB] multicast routing-enable
[SwitchB-Vlanif100] pim sm
[SwitchB-Vlanif200] pim sm
# Configure the domain boundary on VLANIF 100 of SwitchB.

[SwitchB-Vlanif100] pim bsr-boundary
# Configure the domain boundary on VLANIF 200 and VLANIF 400 of SwitchC. Configure
the service boundary of BSR on VLANIF 400 of SwitchE. The configuration on SwitchE is
similar to the configuration on SwitchB, and is not provided here.
# Enable IGMP on the interface connecting SwitchD to the leaf network.
[SwitchD-Vlanif102] igmp enable
Step 4 Configure the C-BSR and C-RP.

# Create Loopback0, and then configure a C-BSR, and a C-RP on Loopback0 on SwitchB. The
configurations of SwitchC and SwitchE are similar to the configuration of SwitchB, and are not
provided here.
[SwitchB] interface loopback 0
[SwitchB-LoopBack0] ip address 1.1.1.1 255.255.255.255
[SwitchB-LoopBack0] pim sm
[SwitchB-LoopBack0] quit
[SwitchB] pim
[SwitchB-pim] c-bsr loopback 0
[SwitchB-pim] c-rp loopback 0
[SwitchB-pim] quit
Step 5 Configure MSDP peer relations.

# Configure the MSDP peer relationship on SwitchB.
[SwitchB] msdp
[SwitchB-msdp] peer 192.168.2.2 connect-interface vlanif200
[SwitchB-msdp] quit
# Configure the MSDP peer relationship on SwitchC.

[SwitchC] msdp
[SwitchC-msdp] peer 192.168.2.1 connect-interface vlanif200
[SwitchC-msdp] quit
# Configure the MSDP peer relationship on SwitchE.

[SwitchE] msdp
[SwitchE-msdp] peer 192.168.4.1 connect-interface vlanif400
[SwitchE-msdp] quit

# Run the display bgp peer command to view the BGP peer relationship between Switches. For
example, the following information shows the BGP peer relationship on SwitchB and SwitchC:
<SwitchB> display bgp peer
BGP local router ID : 1.1.1.1

Local AS number : 100

Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ Up/Down State

PrefRcv
192.168.2.2 4 200 24 21 0 00:13:09 Established 6
<SwitchC> display bgp peer
BGP local router ID : 2.2.2.2

Local AS number : 200
Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ Up/Down State

PrefRcv
192.168.2.1 4 100 18 16 0 00:12:04 Established 1
# Run the display bgp routing-table command to view the BGP routing table on a Switch. For
example, the BGP routing table displayed on SwitchC is as follows:
<SwitchC> display bgp routing-table
Total Number of Routes: 5

BGP Local router ID is 2.2.2.2
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 1.1.1.1/32 192.168.2.1 0 0 100?
*>i 2.2.2.2/32 0.0.0.0 0 0 ?
*> 192.168.2.0 0.0.0.0 0 0 ?
*> 192.168.2.1/32 0.0.0.0 0 0 ?
*> 192.168.2.2/32 0.0.0.0 0 0 ?
# Run the display msdp brief command to view the status of the MSDP peer relationship
between Switches. The information about establishing MSDP peer relationship among SwitchB,
SwitchC and SwitchE is as follows:
<SwitchB> display msdp brief

1 1 0 0 0 0

192.168.2.2 UP 00:12:27 200 13 0
<SwitchC> display msdp brief

2 2 0 0 0 0

192.168.2.1 UP 01:07:08 100 8 0
192.168.4.2 UP 00:06:39 200 13 0
<SwitchE> display msdp brief

1 1 0 0 0 0
192.168.4.1 UP 00:15:32 200 8 0
# Run the display msdp peer-status command to view the details about MSDP peer relations
between Switches. The details displayed on SwitchB are as follows:

<SwitchB> display msdp peer-status

MSDP Peer 192.168.2.2, AS 200
Description:
State: Up
Resets: 0
Connection interface: vlanif200 (192.168.2.1)
Import policy: none
Export policy: none
Policy to accept SA-Request messages: none
Sending SA-Requests status: disable
# Run the display pim routing-table command to view the PIM routing table on a Switch. When
multicast sources 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/24), Receiver (10.110.2.2/24) in PIM-SM2 can
receive the multicast data. The PIM routing tables displayed on SwitchB and SwitchC are as
follows:
(10.110.1.2, 225.1.1.1)
RP: 1.1.1.1(local)
Protocol: pim-sm, Flag: SPT EXT ACT
UpTime: 00:00:42
1: vlanif100

Total 1 (*, G) entry; 2 (S, G) entries
(*, 225.1.1.1)
RP: 2.2.2.2(local)
Protocol: pim-sm, Flag: WC RPT
UpTime: 00:13:46
Upstream interface: NULL,
1: vlanif300,
(10.110.1.2, 225.1.1.1)

RP: 2.2.2.2
Protocol: pim-sm, Flag: SPT MSDP ACT
UpTime: 00:00:42
1: vlanif300
(10.110.3.2, 225.1.1.1)
RP: 2.2.2.2
Protocol: pim-sm, Flag: SPT MSDP ACT
UpTime: 00:00:42
1: vlanif300
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 101
#
#
interface Vlanif100
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface Vlanif200
ip address 10.110.1.1 255.255.255.0
pim sm
#
#
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 10.110.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 sm
pim bsr-boundary
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
#
#
bgp 100
router-id 1.1.1.1
peer 192.168.2.2 as-number 200
import-route ospf 1
#
ospf 1
import-route bgp
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 1.1.1.1 0.0.0.0
#
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 sm
pim bsr-boundary
#
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 sm
pim bsr-boundary
#
#
#


#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
pim sm
#
bgp 200
router-id 2.2.2.2
import-route ospf 1
#
ospf 1
import-route bgp
area 0.0.0.0
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
network 2.2.2.2 0.0.0.0
#
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
#
#
#
ospf 1
area 0.0.0.0
network 192.168.3.0 0.0.0.255
network 10.110.2.0 0.0.0.255
#
return
l Configuration file of SwitchE
#
sysname SwitchE
#
vlan batch 400 500
#
#
interface Vlanif400
ip address 192.168.4.2 255.255.255.0

pim sm
pim bsr-boundary
#
interface Vlanif500
ip address 192.168.5.1 255.255.255.0
pim sm
#
#
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.4.0 0.0.0.255
network 192.168.5.0 0.0.0.255
network 3.3.3.3 0.0.0.0
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
msdp
#
return
l Configuration file of SwitchF

#
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
#
#
#
ospf 1
area 0.0.0.0
network 192.168.5.0 0.0.0.255
network 10.110.3.0 0.0.0.255
#
return
7.12.2 Example for Configuring Inter-AS Multicast by Using Static

RPF Peers

As shown in Figure 7-2, two ASs exist on the network. Each AS contains one or more PIM-SM
domains; each PIM-SM domain has 0 or 1 multicast source and receiver. MSDP peers need to
be set up between PIM-SM domains to share the information of the multicast source.
Figure 7-2 Networking diagram for configuring inter-AS multicast by using static RPF peers
AS100 AS200 Loopback0

2.2.2.2/32
SwitchE
Loopback0 GE1/0/0
1.1.1.1/32 GE2/0/0 GE1/0/0
GE3/0/0 SwitchD
SwitchC GE2/0/0 PIM-SM2
GE1/0/0 Receiver
GE1/0/0
SwitchB 3.3.3.3/32 Receiver
GE2/0/0 Loopback0
PIM-SM1
GE2/0/0
GE3/0/0 SwitchG GE3/0/0
GE1/0/0 GE1/0/0 GE2/0/0
S1 GE2/0/0
SwitchF
SwitchA GE1/0/0
PIM-SM3
S2
BGP peers
Switch Interface VLANIF interface IP address
GE 2/0/0 VLANIF 400 192.168.4.2/24
GE 3/0/0 VLANIF 101 10.110.1.1/24
GE 2/0/0 VLANIF 200 192.168.2.2/24
GE 2/0/0 VLANIF 400 192.168.4.1/24
GE 2/0/0 VLANIF 200 192.168.2.1/24
GE 3/0/0 VLANIF 102 10.110.2.1/24
SwitchF GE 1/0/0 VLANIF 500 192.168.5.1/24
GE 2/0/0 VLANIF 600 192.168.6.1/24
SwitchG GE 1/0/0 VLANIF 103 10.110.3.1/24
GE 2/0/0 VLANIF 600 192.168.6.2/24
GE 3/0/0 VLANIF 104 10.110.4.1/24

Set up an MSDP peer on the RP in each PIM-SM domain. Establish the static RPF peer
relationship between MSDP peers. In this way, the source information can be transmitted across
domains without changing unicast topology.
1. Configure IP addresses for the interfaces on each Switch, configure OSPF in the AS,
configure EBGP between ASs, and import BGP and OSPF routes into each other's routing
table.
2. Enable multicast on all Switches and PIM-SM on all interfaces and enable IGMP on the
interfaces at the user side. Configure Loopback0, C-BSR, and C-RP. The Loopback 0
interfaces on SwitchC, SwitchD, and SwitchF function as the C-BSR and the C-RP of each
PIM-SM domain.
3. Establish MSDP peer relationship between RPs of each domain. Establish the MSDP peer
relationship between SwitchC and SwitchD and establish the MSDP peer relationship
between SwitchC and SwitchF.
4. Specify a static RPF peer for the MSDP peer. The static RPF peers of SwitchC are
SwitchD and SwitchF. SwitchD and SwitchF have only one static RPF peer, namely,
SwitchC. According to RPF rules, Switches receive SA messages from static RPF peers.
Data Preparation
l Number of the AS that SwitchA, SwitchB, and SwitchC belong to: 100
l Router IDs of SwitchA, SwitchB, and SwitchC: 1.1.1.3, 1.1.1.2 and 1.1.1.1
l Number of the AS that SwitchD and SwitchE belong to: 200
l Router IDs of SwitchD and SwitchE: 2.2.2.2 and 2.2.2.1
l Number of the AS that SwitchF and SwitchG belong to: 200
l Router ID of SwitchF: 3.3.3.3
l SwitchC uses the list-df policy to filter the SA messages from SwitchD and SwitchF.
l SwitchD and SwitchF use the list-c policy to filter the SA messages from SwitchC.
NOTE
This configuration example describes only the commands used to configure static RPF peers.
Procedure
Step 1 Configure the IP addresses of interfaces and the unicast routing protocol
# According to Figure 7-2, configure IP addresses and masks for the interfaces of each
Switch. Configure OSPF in the AS. Configure EBGP between SwitchA and SwitchF, and
between SwitchB and SwitchE. Import BGP and OSPF routes into each other's routing table.
Ensure that the Switches can communicate with each other at the network layer. Ensure the
dynamic route update between routers through the unicast routing protocol. The configuration
procedure is not provided here.
Step 2 Enable multicast on all Switches and PIM-SM on all interfaces, and enable the IGMP function
on the interfaces connected to the hosts. In addition, configure the service boundary of BSR on
the interfaces of Switches on the AS boundary.
# Enable multicast all the Switches and enable PIM-SM on each interface. The configurations
of other Switches are similar to configuration of SwitchC, and are not provided here.


# Configure the service boundary of BSR on VLANIF 500 of SwitchA, VLANIF 200 of
SwitchB, VLANIF 200 of SwitchE, and VLANIF 500 of SwitchF. The configurations of
SwitchB, SwitchE, and SwitchF are similar to configuration of SwitchA, and are not provided
here.
[SwitchA-Vlanif500] pim bsr-boundary
Step 3 Configure Loopback0, C-BSR, and C-RP.

# Configure loopback0, C-BSR, and C-RP on SwitchC, SwitchD, and SwitchF. The
configurations of SwitchD and SwitchF are similar to the configuration of SwitchC, and are not
provided here.
[SwitchC] interface loopback 0
[SwitchC-LoopBack0] ip address 1.1.1.1 255.255.255.255
[SwitchC-LoopBack0] pim sm
[SwitchC-LoopBack0] quit
[SwitchC] pim
[SwitchC-pim] c-bsr loopback 0
[SwitchC-pim] c-rp loopback 0
[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
[SwitchC-msdp] quit
# Configure SwitchC as the static RPF peer of SwitchD and SwitchF. The configuration of
SwitchF is similar to the configuration of SwitchD, and is not provided 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

# Run the display bgp peer command to view the status of the BGP peer relationship between
Switches. No output information is displayed on SwitchC, which indicates that no BGP peer
relationship is set up between SwitchC and SwitchD, and between SwitchC and SwitchF.
between Switches. When multicast source S1 in the PIM-SM1 domain sends multicast packets,
the receivers in the PIM-SM2 and PIM-SM3 domains can receive the packets. For example, the
displayed information of MSDP peers on SwitchC, SwitchD and SwitchF is as follows:


2 2 0 0 0 0

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

1 1 0 0 0 0

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

1 1 0 0 0 0

192.168.4.1 UP 00:16:40 ? 13 0
----End
Configuration Files
l Configuration file of SwitchA The configuration files of SwitchD and SwitchF are similar
to the configuration file of SwitchA, and are not provided here.
#
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 sm
pim bsr-boundary
#
#
#
#
ospf 1
area 0.0.0.0
network 192.168.4.0 0.0.0.255
network 192.168.5.0 0.0.0.255
network 10.110.1.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 Vlanif 400
ip address 192.168.4.1 255.255.255.0
pim sm
#
#
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
network 1.1.1.1 0.0.0.0
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
ip ip-prefix list-df permit 192.168.0.0 16 greater-equal 16 less-equal 32
#
msdp
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 LoopBack0
ip address 2.2.2.2 255.255.255.255
pim sm
#
ospf 1

area 0.0.0.0
network 192.168.3.0 0.0.0.255
network 2.2.2.2 0.0.0.0
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
ip ip-prefix list-c 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
l Configuration file of SwitchF
#
sysname SwitchF
#
vlan batch 500 600
#
#
interface Vlanif500
ip address 192.168.5.1 255.255.255.0
pim sm
pim bsr-boundary
#
interface Vlanif600
ip address 192.168.6.1 255.255.255.0
pim sm
#
#
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.5.0 0.0.0.255
network 192.168.6.0 0.0.0.255
network 3.3.3.3 0.0.0.0
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
ip ip-prefix list-c permit 192.168.0.0 16 greater-equal 16 less-equal 32
#
msdp
static-rpf-peer 192.168.4.1 rp-policy list-c
#
return
l Configuration file of SwitchG
#
sysname SwitchG
#
#

#
interface Vlanif103
ip address 10.110.3.1 255.255.255.0
pim sm
#
interface Vlanif104
ip address 10.110.4.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif600
ip address 192.168.6.2 255.255.255.0
pim sm
#
#
#
#
ospf 1
area 0.0.0.0
network 192.168.6.0 0.0.0.255
network 10.110.3.0 0.0.0.255
network 10.110.4.0 0.0.0.255
#
return
7.12.3 Example for Configuring Anycast RP
As shown in Figure 7-3, a PIM-SM domain contains multiple multicast sources and receivers.
The MSDP peer relationship needs to be set up in the PIM-SM domain to implement RP load
balancing.

Figure 7-3 Networking diagram for configuring anycast RP
Receiver SwitchB
user2
GE2/0/0 GE1/0/0
Loopback10
S1 PIM-SM
GE3/0/0 GE2/0/0
Source
Loopback1 SwitchD
Source
GE1/0/0 GE1/0/0 S2
SwitchA Loopback0
GE2/0/0 Loopback0
GE1/0/0
GE2/0/0
Loopback1 GE1/0/0
GE2/0/0
SwitchC GE3/0/0 SwitchE
Receiver
Loopback10 user1
MSDP peers
Switch Interface VLANIF interface IP address

GE 2/0/0 VLANIF 101 10.110.1.2/24
GE 2/0/0 VLANIF 102 10.110.2.2/24
GE 2/0/0 VLANIF 101 10.110.1.1/24
GE 3/0/0 VLANIF 104 10.110.4.1/24
Loopback10 10.1.1.1/32
GE 2/0/0 VLANIF 102 10.110.2.1/24
GE 3/0/0 VLANIF 103 10.110.3.1/24
Loopback10 10.1.1.1/32
GE 2/0/0 VLANIF 100 192.168.1.2/24
Configure anycast RPs. Then the receiver sends a Join message to the nearest RP and the
multicast source sends a Register message to the nearest RP.

1. Configure IP addresses for the interfaces of each Switch and configure OSPF in the PIM-
SM domain.
2. Enable multicast on all Switches and PIM-SM on all interfaces and enable the IGMP
function on the interfaces connected the hosts.
3. Configure Loopback10 interfaces on SwitchC and SwitchD. Configure C-RPs on
Loopback10 interfaces, and configure the C-BSR on Loopback1.
4. Configure MSDP peers on Loopback0 interfaces of SwitchC and SwitchD. According to
RPF rules, the Switches receive SA messages from the source RP.
Data Preparation
l Router ID of SwitchC: 1.1.1.1
l Router ID of SwitchD: 2.2.2.2
NOTE
This configuration example describes only the commands used to configure anycast RP.
Procedure
Step 1 Configure the IP addresses of interfaces and the unicast routing protocol
# According to Figure 7-3, configure IP addresses and masks for the interfaces in the PIM-SM
domain. Configure the OSPF protocol between Switches. The configuration procedure is not
provided here.
Step 2 Enable multicast and configure PIM-SM.
# Enable multicast on all Switches, and PIM-SM on all interfaces. Enable the IGMP function
on the interfaces at the host side. The configurations of other Switches are similar to
configuration of SwitchC, and are not provided here.
Step 3 Configure Loopback1, Loopback10, C-BSR, and C-RP.

# Configure the same address for Loopback1 and Loopback10 on both SwitchC and SwitchD.
Configure C-BSR on Loopback1 and C-RP on Loopback 10. The configuration of SwitchD is
similar to configuration of SwitchC, and is not provided here.

[SwitchC] pim
[SwitchC-pim] c-bsr loopback 1
[SwitchC-pim] c-rp loopback 10
[SwitchC-pim] quit
Step 4 Configure Loopback0 interfaces and MSDP peers.

# Configure the MSDP peer on Loopback0 of SwitchC.
[SwitchC] msdp
[SwitchC-msdp] originating-rp loopback0
[SwitchC-msdp] peer 2.2.2.2 connect-interface loopback0
[SwitchC-msdp] quit
# Configure the MSDP peer on Loopback0 of SwitchD.

[SwitchD] interface loopback 0
[SwitchD-LoopBack0] ip address 2.2.2.2 255.255.255.255
[SwitchD-LoopBack0] pim sm
[SwitchD-LoopBack0] quit
[SwitchD] msdp
[SwitchD-msdp] originating-rp loopback0
[SwitchD-msdp] peer 1.1.1.1 connect-interface loopback0
[SwitchD-msdp] quit

between Switches. Information about MSDP peers on SwitchC and SwitchD is as follows:
1 1 0 0 0 0

2.2.2.2 Up 00:10:17 ? 0 0
<SwitchD> display msdp brief

1 1 0 0 0 0
1.1.1.1 Up 00:10:18 ? 0 0
# Run the display pim routing-table command to view the PIM routing table on a Switch. In
the PIM-SM domain, multicast source S1 (10.110.5.100/24) sends multicast packets to multicast
group G (225.1.1.1). User 1 that joins G receives the multicast packets. Comparing information
about the PIM routing tables on SwitchC and SwitchD, you can find that SwitchC is the valid
RP. That is, S1 registers to SwitchC, and User 1 sends a Join message to SwitchC.
(*, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:28:49


1: vlanif104
Protocol: static, UpTime: 00:28:49, Expires: -
(10.110.5.1, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: SPT 2MSDP ACT
UpTime: 00:02:26
1: vlanif104
No output information is displayed.

# User 1 leaves group G, and multicast source S1 stops sending multicast packets to G. You can
run the reset multicast routing-table all and reset multicast forwarding-table all commands
to clear the multicast routing entries and multicast forwarding entries on SwitchC.
<SwitchC> reset multicast routing-table all
<SwitchC> reset multicast forwarding-table all
# User 2 joins group G, and multicast source S2 (10.110.6.100/24) sends multicast packets to
G. Comparing information about the PIM routing tables on SwitchC and SwitchD, you can find
that SwitchD is the valid RP. That is, S2 registers to SwitchD, and User 2 sends a Join message
to SwitchD.
No output information is displayed.

(*, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: WC RPT
UpTime: 00:07:23
Upstream interface: NULL,
1: vlanif103,
(10.110.6.100, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: SPT 2MSDP ACT
UpTime: 00:10:20
1: vlanif103
----End

Configuration Files
l Configuration file of SwitchA The configuration files of SwitchB and SwitchE are similar
to the configuration file of SwitchA, and are not provided here.
#
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
#
#
#
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
l Configuration file of SwitchC The configuration file of SwitchD IS similar to the

configuration file of SwitchC, and is not provided here.
#
sysname SwitchC
#
#
#
interface Vlanif100
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface Vlanif101
ip address 10.110.1.1 255.255.255.0
pim sm
#
interface Vlanif104
ip address 10.110.4.1 255.255.255.0
igmp enable
pim sm
#
#
#
#

interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
pim sm
#
interface LoopBack10
ip address 10.1.1.1 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 10.110.4.0 0.0.0.255
network 1.1.1.1 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.1 0.0.0.0
network 192.168.1.0 0.0.0.255
#
pim
c-bsr LoopBack1
c-rp LoopBack10
#
msdp
originating-rp LoopBack0
peer 2.2.2.2 connect-interface LoopBack0
#
return

Configuration Guide - Multicast 8 IPv4 Multicast VPN Configuration
8 IPv4 Multicast VPN Configuration
About This Chapter
With wide applications of the VPN technology, the requirements for operating multicast services
over the VPN are increasingly stringent. Multicast VPN is mainly used in the MPLS/BGP VPN
for multicast data transmission.
8.1 Overview of IPv4 Multicast VPN
This section takes the networking where the public network PE supports multi-instance IPv4
multicast VPN as an example to describe concepts of the IPv4 multicast VPN and networking
requirements for implementing the IPv4 multicast VPN.
8.2 IPv4 Multicast VPN Supported by the S9300
The system supports multiple IPv4 multicast VPN features, including MD VPNs, share-MDT
and switch-MDT switchover, and inter-AS MD VPNs.
8.3 Configuring Basic MD VPN Functions
By configuring the IPv4 multicast VPN through the MD solution, you can enable the
transmission of private multicast data over a public network. In this manner, multicast data in
the private network can traverse the public network and finally reach the receiver.
8.4 Configuring Switch-MDT Switchover
When multicast data packets are forwarded through the share-MDT in the public network, the
packets are forwarded to all PEs in the same VPN instance. Therefore, the high rate of multicast
data packets in the VPN will increase the burden on the PE. To solve this problem, you can
configure share-MDT and switch-MDT switchover to implement on-demand multicast, thereby,
saving bandwidth resource on the network.
8.5 Maintaining IPv4 Multicast VPN
Maintaining the IPv4 multicast VPN involves monitoring the running status of the IPv4 multicast
VPN and controlling the output of logs.
Examples for configuring the IPv4 multicast VPN, including the single-AS MD VPN and inter-
AS MD VPN, are provided.

8.1 Overview of IPv4 Multicast VPN

This section takes the networking where the public network PE supports multi-instance IPv4
multicast VPN as an example to describe concepts of the IPv4 multicast VPN and networking
requirements for implementing the IPv4 multicast VPN.
NOTE
The G48SBC or G48TBC board does not support multicast VPN.
TheS9300 implements multicast data transmission based on MPLS/BGP VPN.
As shown in Figure 8-1, when multicast VPN is deployed in the network, the network carries
three separate multicast services at the same time, that is, VPN A instance, VPN B instance, and
the public network instance. A multicast switch PE at the edge of the public network supports
multi-instance. The PE acts as multiple multicast switchs that run separately. Each instance
corresponds to a plane. The three planes are isolated.
Figure 8-1 Multicast VPN based on multi-instance
site4 PE2
site6
MD B
site5 PE1
VPN instance B
P
PE2
PE1
PIM
PE3
Public instance
site2
MD A PE2
site1
PE1
site3
VPN instance A PE3
The following takes VPN A instance as an example to explain multicast VPN.
l S1 belongs to VPN A. S1 sends multicast data to G, a multicast group.

l Among all possible data receivers, only members of VPN A (Site 1, Site 2, and Site 3) can
receive multicast data from S1.
l Multicast data is transmitted among sites in the public network and each site in multicast
mode.

To implement multicast VPN, the following network conditions need to be met:
l Each site supports multicast based on VPN instances.

l Public network supports multicast based on the public network instance.
l PE device supports multi-instance multicast:
– Connecting sites through a VPN instance, and supporting multicast based on the VPN
instance
– Connecting the public network through the public instance, and supporting multicast
based on the public network instance
– Supporting information communication and data switching between the public network
instance and the VPN instance
8.2 IPv4 Multicast VPN Supported by the S9300

The system supports multiple IPv4 multicast VPN features, including MD VPNs, share-MDT
and switch-MDT switchover, and inter-AS MD VPNs.
MD VPN
The S9300 applies Multicast Domain (MD) to implement multicast VPN, which is called MD
VPN. In an MD, VPN data is transmitted through the Multicast Tunnel (MT).
The greatest advantage of the MD solution is that only PEs are required to support multi-instance.
MD neither needs to upgrade CEs and Ps, nor modify the previous Protocol Independent
Multicast (PIM) configuration on CEs and Ps. That is, the MD solution is transparent to CEs
and Ps.
Users can bind Share-Group to Multicast Tunnel Interfaces (MTIs), and set MTI parameters.
Share-Multicast Distribution Tree

For a VPN instance, data transmission in the public network is transparent. The VPN data is
seamlessly connected at MTIs on PEs: The VPN instance only knows that after it sends the VPN
data through an MTI on local PE, and the remote PE can receive the data through an MTI.
Actually, the data experiences the complex public network transmission process, that is,
multicast distribution tree (MDT) transmission.
The MDT that takes the address of Share-group as the group address is called Share-MDT. VPNs
use Share-Group to uniquely identify a Share-MDT.
Multicast can be enabled in a PIM-SM network or a PIM-DM network. In the two different
modes, the process of setting up a Share-MDT is different.
Switch-MDT Switchover
When multicast data is forwarded through a Share-MDT in the public network, the multicast
data is forwarded to all PEs that support the same VPN instance, regardless of whether there is
a receiver in the site connected to PEs. When the rate of VPN multicast data is higher, it may
lead to data flooding, which wastes the network bandwidth and adds load to PEs.
The S9300 optimizes the MD. Special Switch-MDTs is set up between PEs connected to VPN
receivers and PEs connected to the VPN multicast source for VPN multicast data of a high rate

flowing to the public network. The multicast data flow is then switched from the Share-MDT
to the Switch-MDT. Multicast data can thus be transmitted on demand.
Users can configure the switching conditions of a Switch-MDT.
MD VPN across Multi-AS

When a VPN covers multiple ASs, it is necessary to connect VPN nodes among different ASs.
The following lists methods used by MD VPN to realize inter-AS multicast:
l VPN instance-to-VPN Instance connection method

l Multi-hop EBGP connection method
NOTE
For detailed implementation process, refer to the chapter "Multicast VPN" in the Quidway S9300 Terabit
Routing Switch Feature Description - IP Multicast.
8.3 Configuring Basic MD VPN Functions

By configuring the IPv4 multicast VPN through the MD solution, you can enable the
transmission of private multicast data over a public network. In this manner, multicast data in
the private network can traverse the public network and finally reach the receiver.

Before configuring basic MD VPN functions, familiarize yourself with the applicable
environment, pre-configuration tasks, and required data. This can help you complete the
configuration task quickly and accurately.
To implement multicast transmission in a VPN network, ensure that the VPN network works
normally. To enable a PE to receive information from multiple VPNs, the PE needs to
simultaneously support the public network instance and the VPN instance. The public network
is responsible for communicating with Ps, and each VPN instance is responsible for
communicating with each CE.
Configure multicast VPN by using the MD solution. Set up Share-MDT to forward multicast
packets. When the multicast forwarding rate exceeds the threshold, Share-MDT is switched to
Switch-MDT.
Before configuring basic MD VPN functions, complete the following tasks:

l Configuring MPLS/BGP VPN
l Configuring public network multicast
Data Preparation
To configure basic MD VPN functions, you need the following data.

No. Data
1 VPN instance name and Route Distinguisher
2 Share-Group address
3 Address and MTU of MTI
8.3.2 Enabling IP Multicast Routing

Before configuring basic MD VPN functions, enable IP multicast routing.
Context
Do as follows on the PE switch:
Procedure
Step 1 Run:
system-view
Step 2 Run:
IP multicast routing is enabled in the public network instance.
Step 3 Run:
Step 4 Run:
route-distinguisher route-distinguisher
The RD of the VPN instance is configured.
Step 5 Run:
IP multicast routing is enabled in the VPN instance.
----End
8.3.3 Configuring the Eth-Trunk as a Multicast Loopback Interface
Context
On a multicast VPN, all multicast data is processed by the GRE board. Therefore, an Eth-Trunk
must be configured, and a physical port on the GRE board must be added to the Eth-Trunk so
that multicast data can be forwarded to the GRE board for processing.

Procedure
Step 1 Run:
system-view

Step 2 Run:
interface eth-trunk trunk-id
The Eth-Trunk interface view is displayed.

Step 3 Run:
service type multicast-tunnel
The Eth-Trunk is configured as a multicast loopback interface.

This command does not take effect if the Eth-Trunk contains member interfaces or other services
are configured on the Eth-Trunk. In addition, this command can run on only one Eth-Trunk of
a device.
Step 4 Run:
trunkport interface-type interface-number
A physical port is added to the Eth-Trunk.

The member interfaces in the Eth-Trunk must support the multicast tunnel service.
An Eth-Trunk set up between boards cannot be configured as a multicast loopback interface.
----End
8.3.4 Configuring Share-Group and Binding an MTI

When configuring the IPv4 multicast VPN, you need to configure a share-group address and the
MTI to be bound to the VPN instance. On one PE, different VPN instances cannot have the same
share-group address.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
multicast-domain share-group group-address binding mtunnel number
A share group is configured. The system automatically creates an MTI, and then binds the share
group to the MTI and binds the MTI to the VPN instance.

NOTE
After an MTI is created using the command in this step, the system automatically configures PIM on the
MTI. You do not need to configure PIM on this MTI.
PIM-SM is enabled on an MTI by default. If a physical interface configured with a PIM mode exists in the
same VPN with an MTI, the PIM mode of the MTI will be the same as that of the physical interface.
----End
8.3.5 Configuring an MTI

An MTI can send and receive multicast data only after being enabled with the multicast function.
Context
Procedure
l 1. Run:
system-view

2. Run:
interface mtunnel number
The MTI interface view is displayed.

3. Run:
pim sm
or run:
pim dm
PIM is enabled on the MTI.
The PIM mode is the same as the PIM mode of the VPN that the MTI belongs to.
4. Run:
ip address ip-address { mask | mask-length }
The address of the MTI is configured.
NOTE
The MTI address must be the same as the IP address that is used to set up the IBGP peer
relationship on the PE in the public network. Otherwise, the VPN multicast packets received
on the MTI cannot pass the RPF check.
----End

After basic MD VPN functions are configured, you can check information about the share-group
and MTI of a specified VPN instance to ensure normal running of the VPN.

Procedure
l Run the display multicast-domain vpn-instance vpn-instance-name share-group
[ local | remote ] command to check Share-Group information of a specified VPN instance
in an MD.
l Run the display pim vpn-instance vpn-instance-name interface mtunnel interface-
number [ verbose ] command to check information about an MTI.
----End
8.4 Configuring Switch-MDT Switchover

packets are forwarded to all PEs in the same VPN instance. Therefore, the high rate of multicast
data packets in the VPN will increase the burden on the PE. To solve this problem, you can
configure share-MDT and switch-MDT switchover to implement on-demand multicast, thereby,
saving bandwidth resource on the network.

Before configuring share-MDT and switch-MDT switchover, familiarize yourself with the
applicable environment, pre-configuration tasks, and required data. This can help you complete
the configuration task quickly and accurately.
packets are forwarded to all PEs that support the same VPN instance, regardless of whether there
is a receiver in the site to which a PE is connected. When the rate for forwarding VPN multicast
data packets is high, the packets may be flooded in the public network. This wastes network
bandwidth and increases the load of PEs.
In the S9300, you can determine whether to perform Switch-MDT switchover. If Switch-MDT
switchover is not configured, MDs use Share-MDT to transmit VPN multicast data forever.
l When the rate of the VPN multicast data entering the public network exceeds the threshold,
the VPN multicast data can be switched from Share-MDT to a specified Switch-MDT. On-
demand multicast is thus implemented.
l After the VPN multicast data is switched to the switch-MDT, the switchover conditions
may not be met. In this case, the VPN multicast data can be reversely switched from Switch-
MDT to Share-MDT.
Before configuring Switch-MDT switchover, complete the task of Configuring Basic MD VPN
Functions.
Data Preparation
To configure Switch-MDT switchover, you need the following data.

No. Data
1 VPN instance name
2 The address range and mask of the switch-group-pool of Switch-MDT
3 Switching threshold
4 Delay for switching from Share-MDT to Switch-MDT
5 Delay for switching from Switch-MDT to Share-MDT
8.4.2 (Optional) Setting Switching Parameters of Switch-MDT

To reduce the burden on the PE and save bandwidth resources, you can establish a switch-MDT
for multicast data packets flowing from the VPN to the public network and switch the multicast
data packets from the share-MDT to the switch-MDT.
Context
NOTE
This configuration is optional. If this configuration is not done, Switch-MDT switchover cannot be
performed and Share-MDT is always used to transmit VPN multicast data.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
multicast-domain switch-group-pool switch-group-pool { network-mask | network-mask-
length } [ threshold threshold-value | acl { advanced-acl-number | acl-name } ] *
The switch-group-pools of Switch-MDT and switch conditions are configured.

l switch-group-pool: specifies a switch-group-pool. It's suggested that the same VPN instance
on different PEs are configured with the same switch-group-pool. On a PE, the Switch-Group
address ranges to which different VPNs correspond cannot overlap.
l threshold-value: Specifies the threshed. By default, it is 0 kbit/s.
l { advanced-acl-number | acl-name }: specifies the advanced ACL filtering rules. By default,
packets are not filtered.
multicast-domain switch-delay switch-delay

The delay for switching to Switch-MDT is configured.
By default, the delay is 5 seconds.

multicast-domain holddown-time interval
The duration for keeping the rate of VPN multicast data lower than the threshold before reversely
switching from Switch-MDT to Share-MDT is set.
By default, the delay for switching from Switch-MDT to Share-MDT is 60 seconds.
----End

After share-MDT and switch-MDT switchover is configured, you can check information about
the switch-group sent and received by a specified VPN instance in the MD to ensure normal
running of the VPN.
Procedure
l Run the following commands to check Switch-Group information received by a specified
VPN instance in the MD.
– display multicast-domain vpn-instance vpn-instance-name switch-group receive
brief
[ active | group group-address | sender source-address | vpn-source-address [ mask
{ source-mask-length | source-mask } ] | vpn-group-address [ mask { group-mask-
length | group-mask } ] ] *
l Run the display multicast-domain vpn-instance vpn-instance-name switch-group
send [ group group-address | reuse interval | vpn-source-address [ mask { source-mask-
length | source-mask } ] | vpn-group-address [ mask { group-mask-length | group-
mask } ] ] * command to check Switch-Group information sent by a specified VPN instance
in the MD.
----End
8.5 Maintaining IPv4 Multicast VPN

Maintaining the IPv4 multicast VPN involves monitoring the running status of the IPv4 multicast
VPN and controlling the output of logs.
8.5.1 Monitoring the Running Status of IPv4 Multicast VPN

During the routine maintenance of the IPv4 multicast VPN, you can run the display commands
in any view to know the running of the IPv4 multicast VPN.
Context
status of IPv4 Multicast VPN.

Procedure
l Run the display multicast-domain vpn-instance vpn-instance-name share-group
[ local | remote ] command in any view to check information about Share-Group of a
specified VPN instance in an MD.
l Run the following commands in any view to check information about Switch-Group
received by a specified VPN instance in an MD.
brief
[ active | group group-address | sender source-address | vpn-source-address [ mask
{ source-mask-length | source-mask } ] | vpn-group-address [ mask { group-mask-
length | group-mask } ] ] *
l Run the display multicast-domain vpn-instance vpn-instance-name switch-group
send [ group group-address | reuse interval | vpn-source-address [ mask { source-mask-
length | source-mask } ] | vpn-group-address [ mask { group-mask-length | group-
mask } ] ] * command in any view to check information about the Switch-Group sent to a
specified VPN instance in an MD.
----End
8.5.2 Debugging IPv4 Multicast VPN

When a fault occurs during the running of the IPv4 multicast VPN, run the debugging commands
in the user view and locate the fault based on the debugging information. Debugging affects the
performance of the system. So, after debugging, disable it immediately.
Context
CAUTION
Debugging affects the performance of the system. After debugging, run the undo debugging
When a fault occurs during the running of MD VPN, run the debugging command in the user
view to debug MD VPN and locate the fault.
Procedure
l Run the debugging md [ vpn-instance vpn-instance-name | all-instance ] { all | event
[ advanced-acl-number ] | packet } command in the user view to enable multicast
debugging in an MD.
----End
8.5.3 Controlling the Output of Logs

To know the running status of the system or locate a fault through logs, you can enable the output
of logs about the reused switch-group addresses.

Context
In the VPN instance on the source PE, if the number of VPN multicast data flows that need to
be switched is more than the number of group addresses in the switch-group-pool of Switch-
MDT, the group addresses in the switch-group-pool can be used repeatedly.
By default, the logs of the reused Switch-Group addresses are not recorded.
To know the running status of the system or locate a fault through logs, do as follows on the PE:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
multicast-domain log switch-group-reuse
The logs of the reused Switch-Group addresses are recorded.
----End

Examples for configuring the IPv4 multicast VPN, including the single-AS MD VPN and inter-
AS MD VPN, are provided.
8.6.1 Example for Configuring a Single-AS MD VPN
As shown in Figure 8-2, MD is used on the single-AS MPLS/BGP VPN to deploy multicast
services.

Figure 8-2 Networking diagram of a single-AS MD VPN
PC2
VPN
RED
Source2 GE1
CE-Rb
GE2 GE3
PC3
GE1 Loopback1
VPN Loopback1
BLUE GE3 GE3 GE1
GE2 VPN
Loopback1 RED
CE-Bb Public
GE2 GE2
PE-B GE1 P PE-C CE-Rc
GE2 GE3 GE2
Loopback2
GE1
Source1 GE1
GE3
CE-Ra
GE1Loopback1
GE1 GE3 GE2 VPN
GE2
CE-Bc BLUE
VPN GE2 GE1
RED PE-A
PC4
PC1 Loopback1
NOTE
GE1 indicates GigabitEthernet 1/0/0; GE2 indicates GigabitEthernet 2/0/0; GE3 indicates GigabitEthernet
3/0/0.Table 8-1 lists the IP address of each interface in the figure.
Table 8-1 Configurations of the interfaces on switches

Device Interface IP Address Remarks
P GE1: 192.168.6.2/24 -
VLANIF 10
GE2: 192.168.7.2/24 -
VLANIF 20
GE3: 192.168.8.2/24 -
VLANIF 30
Loopback 1: 2.2.2.2/32 Loopback 1 acts as the C-RP for the public

network.
PE-A GE1: 192.168.6.1/24 GE1 belongs to the public network

VLANIF 40 instance.
GE2: 10.110.1.1/24 GE2 belongs to the VPN-RED instance.

VLANIF 50


VLANIF 60
Loopback 1: 1.1.1.1/32 Loopback 1 belongs to the public network

instance.
IBGP peer relationships are set up
between the Loopback 1 interfaces on PE-
A, PE-B, and PE-C.
PE-B GE1: 192.168.7.1/24 GE1 belongs to the public network

VLANIF 70 instance.
GE2: 10.110.3.1/24 GE2 belongs to the VPN-BLUE instance.

VLANIF 80

VLANIF 90

instance.
A, PE-B, and PE-C.
PE-C GE1: 192.168.8.1/24 GE1 belongs to the public network

VLANIF 100 instance.

VLANIF 110
GE3: 10.110.6.1/24 GE3 belongs to the VPN-BLUE instance.

VLANIF 120

instance.
A, PE-B, and PE-C.
Loopback 2: 33.33.33.33/32 Loopback 2 belongs to the VPN-BLUE

instance and acts as the C-RP of the
private network.
CE-Ra GE1: 10.110.7.1/24 -

VLANIF 130
GE2: 10.110.2.2/24 -
VLANIF 140

CE-Bb GE1: 10.110.8.1/24 -

VLANIF 150
GE2: 10.110.3.2/24 -
VLANIF 160
CE-Rb GE1: 10.110.9.1/24 -

VLANIF 170
GE2: 10.110.4.2/24 -
VLANIF 180
GE3: 10.110.12.1/24 -
VLANIF 190
Loopback 1: 22.22.22.22/32 Loopback 1 belongs to the VPN-RED

instance and acts as the C-RP of the
private network.
CE-Rc GE1: 10.110.10.1/24 -

VLANIF 200
GE2: 10.110.5.2/24 -
VLANIF 210
GE3: 10.110.12.2/24 -
VLANIF 220
CE-Bc GE1: 10.110.11.1/24 -

VLANIF 230
GE2: 10.110.6.2/24 -
VLANIF 240
Source1 10.110.7.2/24 Multicast source of VPN-RED
Source 2 10.110.8.2/24 Multicast source of VPN-BLUE
PC1 10.110.1.2/24 Multicast receiver of VPN-RED
PC4 10.110.11.2/24 Multicast receiver of VPN-BLUE

Table 8-2 Networking requirements of the single-AS MD VPN

Item Requirements
Multicast source The multicast source of VPN-RED is Source 1; the receivers of VPN-
and receivers RED are PC1, PC2, and PC3. The multicast source of VPN-BLUE is
Source 2 and the receiver of VPN-BLUE is PC4. The Share-Group
address of VPN-RED is 239.1.1.1; the addresses in the Switch-Group
address pool range from 225.2.2.1 to 225.2.2.16. The Share-Group
address of VPN-BLUE is 239.2.2.2; the addresses in the Switch-Group
address pool range from 225.4.4.1 to 225.4.4.16.
VPN instances to GE2 and GE3 on PE-A belong to the VPN-RED instance; GE1 and
which the interfaces Loopback 1 on PE-A belong to the public network instance; GE2 on
on the PEs belong PE-B belongs to the VPN-BLUE instance; GE3 on PE-B belongs to
the VPN-RED instance; GE1 and Loopback 1 on PE-B belong to the
public network instance; GE2 on PE-C belongs to the VPN-RED
instance; GE3 and Loopback 2 on PE-C belong to the VPN-BLUE
instance; GE1 and Loopback 1 on PE-C belong to the public network
instance.
Routing protocols OSPF is configured on the public network; RIP is configured between
and MPLS PEs and switches (CEs). BGP peer connections are set up between the
Loopback 1 interfaces on PE-A, PE-B, and PE-C. All private network
routes are transmitted along these BGP peer connections. MPLS
forwarding starts on the public network.
Multicast function Multicast is enabled on the P. Multicast is enabled on the public

network instances of PE-A, PE-B, and PE-C. Multicast is enabled on
the VPN-RED instances of PE-A, PE-B, and PE-C. Multicast is
enabled on the VPN-BLUE instances of PE-B and PE-C. Multicast is
enabled on CE-Ra, CE-Rb, CE-Rc, CE-Bb, and CE-Bc.
IGMP IGMP is enabled on GE2 on PE-A, GE1 interfaces of CE-Rb, CE-Rc,

CE-Bb, and CE-Bc.
PIM PIM-SM is enabled on all the private network interfaces of VPN-RED

and VPN-BLUE. PIM-SM is enabled on all the interfaces of Ps and
CEs, and on all the public network interfaces of PEs. Loopback 1 of
the P acts as a C-BSR and C-RP for all the groups. Loopback 1 of the
CE-Rb acts as the C-BSR and C-RP for the private network VPN-RED
for all the groups. Loopback 2 of PE-C acts as the C-BSR and C-RP
for the private network VPN-BLUE for all the groups.
1. Configure MPLS/BGP VPN; ensure that the VPN works normally and unicast routes are
reachable.
2. On the PE, configure Eth-Trunk 10 as the multicast loopback interface.

3. Enable the multicast function and the PIM function on the entire network. Configure the
public network-based multicast between PEs and Ps and configure the VPN instance-based
multicast between PEs and CEs.
4. Configure the identical Share-Group address, MTI, and address pool range of Switch-MDT
for the same VPN instance on each PE.
5. Configure the MTI address of each PE as the IBGP peer interface address on the public
network, and enable PIM on the MTI.
Data Preparation
See Table 8-2 in "Networking Requirements."
Procedure
Step 1 # Configure PE-A.
# Configure the ID of PE-A, enable IP multicast routing on the public network, configure the
ID of the MPLS LSR, and then enable LDP.
[PE-A] router id 1.1.1.1
[PE-A] multicast routing-enable
[PE-A] mpls lsr-id 1.1.1.1
[PE-A] mpls
[PE-A-mpls] quit
[PE-A] mpls ldp
[PE-A-mpls-ldp] quit
# Configure Eth-Trunk 10 as the multicast loopback interface.

[PE-A] interface eth-trunk 10
[PE-A-Eth-Trunk10] trunkport gigabitethernet 3/0/5
[PE-A-Eth-Trunk10] service type multicast-tunnel
[PE-A-Eth-Trunk10] quit
# Create a VPN-RED instance and enter the VPN instance view. Configure the VPN IPv4 prefix
and create ingress and egress routes of the instance. Enable IP multicast routing and configure
the Share-Group. Specify the MTI to be bound to the VPN instance and address pool range of
Switch-MDT.
[PE-A] ip vpn-instance RED
[PE-A-vpn-instance-RED] route-distinguisher 100:1
[PE-A-vpn-instance-RED] vpn-target 100:1 export-extcommunity
[PE-A-vpn-instance-RED] vpn-target 100:1 import-extcommunity
[PE-A-vpn-instance-RED] multicast routing-enable
[PE-A-vpn-instance-RED] multicast-domain share-group 239.1.1.1 binding mtunnel 0
[PE-A-vpn-instance-RED] multicast-domain switch-group-pool 225.2.2.1 28
[PE-A-vpn-instance-RED] quit
# Enable LDP on GigabitEthernet 1/0/0 and start PIM-SM.

[PE-A] interface gigabitethernet 1/0/0
[PE-A-GigabitEthernet1/0/0] port hybrid pvid vlan 40
[PE-A-GigabitEthernet1/0/0] port hybrid untagged vlan 40
[PE-A-GigabitEthernet1/0/0] quit
[PE-A] interface vlanif 40
[PE-A-Vlanif40] ip address 192.168.6.1 24
[PE-A-Vlanif40] pim sm
[PE-A-Vlanif40] mpls
[PE-A-Vlanif40] mpls ldp
# Bind GigabitEthernet 2/0/0 to the VPN-RED instance, and start IGMP and PIM-SM.


[PE-A-Vlanif50] ip binding vpn-instance RED
[PE-A-Vlanif50] igmp enable
# Bind GigabitEthernet 3/0/0 to the VPN-RED instance, and start PIM-SM.

[PE-A-Vlanif60] ip binding vpn-instance RED
# Assign an IP address to Loopback 1 and start PIM-SM.

[PE-A] interface loopback 1
[PE-A-LoopBack1] ip address 1.1.1.1 32
[PE-A-LoopBack1] pim sm
[PE-A-LoopBack1] quit
# Configure an IP address for MTI 0, which must be the same as the IP address of Loopback 1.
The system automatically binds MTI 0 to the VPN-RED instance. Start PIM-SM on the interface.
[PE-A] interface MTunnel 0
[PE-A-MTunnel0] ip address 1.1.1.1 32
[PE-A-MTunnel0] pim sm
[PE-A-MTunnel0] quit
# Configure unicast routing information of BGP, OSPF, and RIP.

[PE-A] bgp 100
[PE-A-bgp] group VPN-G internal
[PE-A-bgp] peer VPN-G connect-interface LoopBack1
[PE-A-bgp] peer 1.1.1.2 group VPN-G
[PE-A-bgp] peer 1.1.1.3 group VPN-G
[PE-A-bgp] ipv4-family vpn-instance RED
[PE-A-bgp-RED] import-route rip 2
[PE-A-bgp-RED] import-route direct
[PE-A-bgp-RED] quit
[PE-A-bgp] ipv4-family vpnv4
[PE-A-bgp-af-vpnv4] peer VPN-G enable
[PE-A-bgp-af-vpnv4] peer 1.1.1.2 group VPN-G
[PE-A-bgp-af-vpnv4] peer 1.1.1.3 group VPN-G
[PE-A-bgp-af-vpnv4] quit
[PE-A-bgp] quit
[PE-A] ospf 1
[PE-A-ospf-1] area 0.0.0.0
[PE-A-ospf-1-area-0.0.0.0] network 1.1.1.1 0.0.0.0
[PE-A-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.255.255
[PE-A-ospf-1-area-0.0.0.0] quit
[PE-A-ospf-1] quit
[PE-A] rip 2 vpn-instance RED
[PE-A-rip-2] network 10.0.0.0
[PE-A-rip-2] import-route bgp cost 3
Step 2 # Configure PE-B.

# Configure the ID of PE-B, enable IP multicast routing of the public network, configure the ID
of the MPLS LSR, and then enable LDP.
[PE-B] router id 1.1.1.2
[PE-B] multicast routing-enable

[PE-B] mpls lsr-id 1.1.1.2

[PE-B] mpls
[PE-B-mpls] quit
[PE-B] mpls ldp
[PE-B-mpls-ldp] quit

[PE-B] interface eth-trunk 10
[PE-B-Eth-Trunk10] trunkport GigabitEthernet 3/0/5
[PE-B-Eth-Trunk10] service type multicast-tunnel
[PE-B-Eth-Trunk10] quit
# Create a VPN-BLUE instance and enter the VPN instance view. Configure the VPN IPv4
prefix and create ingress and egress routes of the instance. Start an IP multicast route and
configure the Share-Group. Specify the MTI to be bound to the VPN instance and switch-
address-pool range of Switch-MDT.
[PE-B] ip vpn-instance BLUE
[PE-B-vpn-instance-BLUE] route-distinguisher 200:1
[PE-B-vpn-instance-BLUE] vpn-target 200:1 export-extcommunity
[PE-B-vpn-instance-BLUE] vpn-target 200:1 import-extcommunity
[PE-B-vpn-instance-BLUE] multicast routing-enable
[PE-B-vpn-instance-BLUE] multicast-domain share-group 239.2.2.2 binding mtunnel 1
[PE-B-vpn-instance-BLUE] multicast-domain switch-group-pool 225.4.4.1 28
and create ingress and egress routes of the instance. Start an IP multicast route and configure
the Share-Group. Specify the MTI to be bound to the VPN instance and switch-address-pool
range of Switch-MDT.
[PE-B] ip vpn-instance RED
[PE-B-vpn-instance-RED] route-distinguisher 100:1
[PE-B-vpn-instance-RED] vpn-target 100:1 export-extcommunity
[PE-B-vpn-instance-RED] vpn-target 100:1 import-extcommunity
[PE-B-vpn-instance-RED] multicast routing-enable
[PE-B-vpn-instance-RED] multicast-domain share-group 239.1.1.1 binding mtunnel 0
[PE-B-vpn-instance-RED] multicast-domain switch-group-pool 225.2.2.1 28

[PE-B] interface gigabitethernet 1/0/0
[PE-B-GigabitEthernet1/0/0] port hybrid pvid vlan 70
[PE-B-GigabitEthernet1/0/0] port hybrid untagged vlan 70
[PE-B-GigabitEthernet1/0/0] quit
[PE-B] interface vlanif 70
[PE-B-Vlanif70] ip address 192.168.7.1 24
[PE-B-Vlanif70] pim sm
[PE-B-Vlanif70] mpls
[PE-B-Vlanif70] mpls ldp
# Bind GigabitEthernet 2/0/0 to the VPN-BLUE instance, and start PIM-SM.

[PE-B-Vlanif80] ip binding vpn-instance BLUE



[PE-B-Vlanif90] ip binding vpn-instance RED

[PE-B] interface loopback 1
[PE-B-LoopBack1] ip address 1.1.1.2 32
[PE-B-LoopBack1] pim sm
[PE-B-LoopBack1] quit
# Configure an IP address for MTI 0, which needs to be the same as the IP address of Loopback
1. Start PIM-SM on the interface.
[PE-B] interface MTunnel 0
[PE-B-MTunnel0] ip address 1.1.1.2 32
[PE-B-MTunnel0] pim sm
[PE-B] interface MTunnel 1
[PE-B-MTunnel1] ip address 1.1.1.2 32
[PE-B-MTunnel1] pim sm

[PE-B] bgp 100
[PE-B-bgp] group VPN-G internal
[PE-B-bgp] peer VPN-G connect-interface LoopBack1
[PE-B-bgp] peer 1.1.1.1 group VPN-G
[PE-B-bgp] peer 1.1.1.3 group VPN-G
[PE-B-bgp] ipv4-family vpn-instance RED
[PE-B-bgp-RED] import-route rip 2
[PE-B-bgp-RED] import-route direct
[PE-B-bgp-RED] quit
[PE-B-bgp] ipv4-family vpn-instance BLUE
[PE-B-bgp-BLUE] import-route rip 3
[PE-B-bgp-BLUE] import-route direct
[PE-B-bgp-BLUE] quit
[PE-B-bgp] ipv4-family vpnv4
[PE-B-bgp-af-vpnv4] peer VPN-G enable
[PE-B-bgp-af-vpnv4] peer 1.1.1.1 group VPN-G
[PE-B-bgp-af-vpnv4] peer 1.1.1.3 group VPN-G
[PE-B-bgp-af-vpnv4] quit
[PE-B-bgp] quit
[PE-B] ospf 1
[PE-B-ospf-1] area 0.0.0.0
[PE-B-ospf-1-area-0.0.0.0] network 1.1.1.2 0.0.0.0
[PE-B-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.255.255
[PE-B-ospf-1-area-0.0.0.0] quit
[PE-B-ospf-1] quit
[PE-B] rip 2 vpn-instance RED
[PE-B-rip-2] network 10.0.0.0
[PE-B-rip-2] import-route bgp cost 3
[PE-B-rip-2] quit
[PE-B] rip 3 vpn-instance BLUE
[PE-B-rip-3] network 10.0.0.0
[PE-B-rip-3] import-route bgp cost 3
Step 3 # Configure PE-C.

# Configure the ID of PE-C, enable IP multicast routing of the public network, configure the ID
of the MPLS LSR, and then enable LDP.
[PE-C] router id 1.1.1.3
[PE-C] multicast routing-enable
[PE-C] mpls lsr-id 1.1.1.3

[PE-C] mpls
[PE-C-mpls] quit
[PE-C] mpls ldp
[PE-C-mpls-ldp] quit

[PE-C] interface eth-trunk 10
[PE-C-Eth-Trunk10] trunkport GigabitEthernet 3/0/5
[PE-C-Eth-Trunk10] service type multicast-tunnel
[PE-C-Eth-Trunk10] quit
and create ingress and egress routes of the instance. Start an IP multicast route and configure
the Share-Group. Specify the MTI to be bound to the VPN instance and switch-address-pool
range of Switch-MDT.
[PE-C] ip vpn-instance RED
[PE-C-vpn-instance-RED] route-distinguisher 100:1
[PE-C-vpn-instance-RED] vpn-target 100:1 export-extcommunity
[PE-C-vpn-instance-RED] vpn-target 100:1 import-extcommunity
[PE-C-vpn-instance-RED] multicast routing-enable
[PE-C-vpn-instance-RED] multicast-domain share-group 239.1.1.1 binding mtunnel 0
[PE-C-vpn-instance-RED] multicast-domain switch-group-pool 225.2.2.1 28
# Create a VPN-BLUE instance and enter the VPN instance view. Configure the VPN IPv4
prefix and create ingress and egress routes of the instance. Start an IP multicast route and
configure the Share-Group. Specify the MTI to be bound to the VPN instance and switch-
address-pool range of Switch-MDT.
[PE-C] ip vpn-instance BLUE
[PE-C-vpn-instance-BLUE] route-distinguisher 200:1
[PE-C-vpn-instance-BLUE] vpn-target 200:1 export-extcommunity
[PE-C-vpn-instance-BLUE] vpn-target 200:1 import-extcommunity
[PE-C-vpn-instance-BLUE] multicast routing-enable
[PE-C-vpn-instance-BLUE] multicast-domain share-group 239.2.2.2 binding mtunnel 1
[PE-C-vpn-instance-BLUE] multicast-domain switch-group-pool 225.4.4.1 28

[PE-C] interface gigabitethernet 1/0/0
[PE-C-GigabitEthernet1/0/0] port hybrid pvid vlan 100
[PE-C-GigabitEthernet1/0/0] port hybrid untagged vlan 100
[PE-C-GigabitEthernet1/0/0] quit
[PE-C] interface vlanif 100
[PE-C-Vlanif100] ip address 192.168.8.1 24
[PE-C-Vlanif100] pim sm
[PE-C-Vlanif100] mpls
[PE-C-Vlanif100] mpls ldp

[PE-C-Vlanif110] ip binding vpn-instance RED
# Bind GigabitEthernet 3/0/0 to the VPN-BLUE instance, and start PIM-SM.


[PE-C-Vlanif120] ip binding vpn-instance BLUE


[PE-C] interface loopback 1
[PE-C-LoopBack1] ip address 1.1.1.3 32
[PE-C-LoopBack1] pim sm
[PE-C-LoopBack1] quit
[PE-C] interface MTunnel 0
[PE-C-MTunnel0] ip address 1.1.1.3 32
[PE-C-MTunnel0] pim sm
[PE-C] interface MTunnel 1
[PE-C-MTunnel1] ip address 1.1.1.3 32
[PE-C-MTunnel1] pim sm
# Bind Loopback 2 to the VPN-BLUE instance, and start PIM-SM.

[PE-C] interface loopback 2
[PE-C-LoopBack2] ip binding vpn-instance BLUE
[PE-C-LoopBack2] ip address 33.33.33.33 32
[PE-C-LoopBack2] pim sm
[PE-C-LoopBack2] quit
# Configure Loopback 2 as the C-BSR and C-RP for VPN-BLUE of the private network.
[PE-C] pim vpn-instance BLUE
[PE-C-pim-BLUE] c-bsr Loopback2
[PE-C-pim-BLUE] c-rp Loopback2
[PE-C-pim-BLUE] quit

[PE-C] bgp 100
[PE-C-bgp] group VPN-G internal
[PE-C-bgp] peer VPN-G connect-interface LoopBack1
[PE-C-bgp] peer 1.1.1.1 group VPN-G
[PE-C-bgp] peer 1.1.1.2 group VPN-G
[PE-C-bgp] ipv4-family vpn-instance RED
[PE-C-bgp-RED] import-route rip 2
[PE-C-bgp-RED] import-route direct
[PE-C-bgp-RED] quit
[PE-C-bgp] ipv4-family vpn-instance BLUE
[PE-C-bgp-BLUE] import-route rip 3
[PE-C-bgp-BLUE] import-route direct
[PE-C-bgp-BLUE] quit
[PE-C-bgp] ipv4-family vpnv4
[PE-C-bgp-af-vpnv4] peer VPN-G enable
[PE-C-bgp-af-vpnv4] peer 1.1.1.1 group VPN-G
[PE-C-bgp-af-vpnv4] peer 1.1.1.2 group VPN-G
[PE-C-bgp-af-vpnv4] quit
[PE-C-bgp] quit
[PE-C] ospf 1
[PE-C-ospf-1] area 0.0.0.0
[PE-C-ospf-1-area-0.0.0.0] network 1.1.1.3 0.0.0.0
[PE-C-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.255.255
[PE-C-ospf-1-area-0.0.0.0] quit
[PE-C-ospf-1] quit
[PE-C] rip 2 vpn-instance RED
[PE-C-rip-2] network 10.0.0.0

[PE-C-rip-2] import-route bgp cost 3

[PE-C-rip-2] quit
[PE-C] rip 3 vpn-instance BLUE
[PE-C-rip-3] network 10.0.0.0
[PE-C-rip-3] import-route bgp cost 3
Step 4 Configure the P.

# Enable IP multicast routing of the public network, configure the ID of the MPLS LSR, and
then enable LDP.
[P] multicast routing-enable
[P] mpls lsr-id 2.2.2.2
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit

[P] interface gigabitethernet 1/0/0
[P-GigabitEthernet1/0/0] port hybrid pvid vlan 10
[P-GigabitEthernet1/0/0] port hybrid untagged vlan 10
[P-GigabitEthernet1/0/0] quit
[P] interface vlanif 10
[P-Vlanif10] ip address 192.168.6.2 24
[P-Vlanif10] pim sm
[P-Vlanif10] mpls
[P-Vlanif10] mpls ldp

[P-Vlanif20] pim sm
[P-Vlanif20] mpls

[P-Vlanif30] pim sm
[P-Vlanif30] mpls

[P] interface loopback 1
[P-LoopBack1] ip address 2.2.2.2 32
[P-LoopBack1] pim sm
[P-LoopBack1] quit
# Configure Loopback 1 as the C-BSR and C-RP for the public network.
[P] pim
[P-pim] c-bsr Loopback1
[P-pim] c-rp Loopback1
# Configure OSPF unicast routing information.

[P] ospf 1

[P-ospf-1] area 0.0.0.0

[P-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[P-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.255.255
[P-ospf-1-area-0.0.0.0] quit
Step 5 Configure CE-Ra.
# Enable IP multicast routing.

[CE-Ra] multicast routing-enable
# Enable PIM-SM on GigabitEthernet 1/0/0.

[CE-Ra] interface gigabitethernet 1/0/0
[CE-Ra-GigabitEthernet1/0/0] port hybrid pvid vlan 130
[CE-Ra-GigabitEthernet1/0/0] port hybrid untagged vlan 130
[CE-Ra-GigabitEthernet1/0/0] quit
[CE-Ra] interface vlanif 130
[CE-Ra-Vlanif130] ip address 10.110.7.1 24
[CE-Ra-Vlanif130] pim sm

[CE-Ra] interface gigabitethernet 2/0/0
[CE-Ra-GigabitEthernet2/0/0] port hybrid pvid vlan 140
[CE-Ra-GigabitEthernet2/0/0] port hybrid untagged vlan 140
[CE-Ra-GigabitEthernet2/0/0] quit
[CE-Ra] interface vlanif 140
[CE-Ra-Vlanif140] ip address 10.110.2.2 24
[CE-Ra-Vlanif140] pim sm
# Configure RIP unicast routing information.

[CE-Ra] rip 2
[CE-Ra-rip-2] network 10.0.0.0
[CE-Ra-rip-2] import-route direct
Step 6 Configure CE-Bb.

[CE-Bb] multicast routing-enable

[CE-Bb] interface gigabitethernet 1/0/0
[CE-Bb-GigabitEthernet1/0/0] port hybrid pvid vlan 150
[CE-Bb-GigabitEthernet1/0/0] port hybrid untagged vlan 150
[CE-Bb-GigabitEthernet1/0/0] quit
[CE-Bb] interface vlanif 150
[CE-Bb-Vlanif150] ip address 10.110.8.1 24
[CE-Bb-Vlanif150] pim sm

[CE-Bb] interface gigabitethernet 2/0/0
[CE-Bb-GigabitEthernet2/0/0] port hybrid pvid vlan 160
[CE-Bb-GigabitEthernet2/0/0] port hybrid untagged vlan 160
[CE-Bb-GigabitEthernet2/0/0] quit
[CE-Bb] interface vlanif 160
[CE-Bb-Vlanif160] ip address 10.110.3.2 24
[CE-Bb-Vlanif160] pim sm

[CE-Bb] rip 3
[CE-Bb-rip-3] network 10.0.0.0
[CE-Bb-rip-3] import-route direct

Step 7 Configure CE-Rb.

[CE-Rb] multicast routing-enable
# Enable PIM-SM and IGMP on GigabitEthernet 1/0/0.

[CE-Rb] interface gigabitethernet 1/0/0
[CE-Rb-GigabitEthernet1/0/0] port hybrid pvid vlan 170
[CE-Rb-GigabitEthernet1/0/0] port hybrid untagged vlan 170
[CE-Rb-GigabitEthernet1/0/0] quit
[CE-Rb] interface vlanif 170
[CE-Rb-Vlanif170] ip address 10.110.9.1 24
[CE-Rb-Vlanif170] pim sm
[CE-Rb-Vlanif170] igmp enable



[CE-Rb] interface loopback 1
[CE-Rb-LoopBack1] ip address 22.22.22.22 32
[CE-Rb-LoopBack1] pim sm
[CE-Rb-LoopBack1] quit
# Configure Loopback 1 as the BSR and RP for the private network VPN-RED.
[CE-Rb] pim
[CE-Rb-pim] c-bsr Loopback1
[CE-Rb-pim] c-rp Loopback1
[CE-Rb-pim] quit

[CE-Rb] rip 2
[CE-Rb-rip-2] network 10.0.0.0
[CE-Rb-rip-2] network 22.0.0.0
[CE-Rb-rip-2] import-route direct
Step 8 Configure CE-Rc.

[CE-Rc] multicast routing-enable

[CE-Rc] interface gigabitethernet 1/0/0
[CE-Rc-GigabitEthernet1/0/0] port hybrid pvid vlan 200
[CE-Rc-GigabitEthernet1/0/0] port hybrid untagged vlan 200
[CE-Rc-GigabitEthernet1/0/0] quit

[CE-Rc] interface vlanif 200

[CE-Rc-Vlanif200] ip address 10.110.10.1 24
[CE-Rc-Vlanif200] pim sm
[CE-Rc-Vlanif200] igmp enable



[CE-Rc] rip 2
[CE-Rc-rip-2] network 10.0.0.0
[CE-Rc-rip-2] import-route direct
Step 9 Configure CE-Bc.

[CE-Bc] multicast routing-enable

[CE-Bc] interface gigabitethernet 1/0/0
[CE-Bc-GigabitEthernet1/0/0] port hybrid pvid vlan 230
[CE-Bc-GigabitEthernet1/0/0] port hybrid untagged vlan 230
[CE-Bc-GigabitEthernet1/0/0] quit
[CE-Bc] interface vlanif 230
[CE-Bc-Vlanif230] ip address 10.110.11.1 24
[CE-Bc-Vlanif230] pim sm
[CE-Bc-Vlanif230] igmp enable

[CE-Bc] interface gigabitethernet 2/0/0
[CE-Bc-GigabitEthernet2/0/0] port hybrid pvid vlan 240
[CE-Bc-GigabitEthernet2/0/0] port hybrid untagged vlan 240
[CE-Bc-GigabitEthernet2/0/0] quit
[CE-Bc] interface vlanif 240
[CE-Bc-Vlanif240] ip address 10.110.6.2 24
[CE-Bc-Vlanif240] pim sm

[CE-Bc] rip 3
[CE-Bc-rip-3] network 10.0.0.0
[CE-Bc-rip-3] import-route direct

After the preceding configurations, PC1, PC2, and PC3 can receive multicast information from
Source 1; PC4 can receive multicast information from Source 2.
----End

Configuration Files
l Configuration file of PE-A
#
sysname PE-A
#
router id 1.1.1.1
#
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
ip vpn-instance RED
route-distinguisher 100:1
vpn-target 100:1 export-extcommunity
vpn-target 100:1 import-extcommunity
#
multicast-domain share-group 239.1.1.1 binding MTunnel 0
multicast-domain switch-group-pool 225.2.2.0 255.255.255.240
#
interface Vlanif40
ip address 192.168.6.1 255.255.255.0
pim sm
mpls
mpls ldp
#
interface Vlanif50
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
ip binding vpn-instance RED
#
interface Vlanif60
ip address 10.110.2.1 255.255.255.0
pim sm
#
interface Eth-Trunk10
#
#
#
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
pim sm
#
interface MTunnel0
ip address 1.1.1.1 255.255.255.255
pim sm
#
bgp 100
group VPN-G internal
peer VPN-G connect-interface LoopBack1

peer 1.1.1.2 group VPN-G

#
ipv4-family unicast
undo synchronization
peer VPN-G enable
peer 1.1.1.2 enable
peer 1.1.1.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer VPN-G enable
peer 1.1.1.2 enable
peer 1.1.1.3 enable
#
ipv4-family vpn-instance RED
import-route rip 2
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 192.168.0.0 0.0.255.255
#
rip 2 vpn-instance RED
network 10.0.0.0
import-route bgp cost 3
#
return
l Configuration file of PE-B
#
sysname PE-B
#
router id 1.1.1.2
#
#
mpls lsr-id 1.1.1.2
mpls
#
mpls ldp
#
ip vpn-instance BLUE
#
ip vpn-instance RED
#
interface Vlanif70
ip address 192.168.7.1 255.255.255.0
pim sm
mpls
mpls ldp
#

interface Vlanif80
ip binding vpn-instance BLUE
ip address 10.110.3.1 255.255.255.0
pim sm
#
#
interface Vlanif90
ip address 10.110.4.1 255.255.255.0
pim sm
#
#
#
#
interface LoopBack1
ip address 1.1.1.2 255.255.255.255
pim sm
#
interface MTunnel0
ip address 1.1.1.2 255.255.255.255
pim sm
#
interface MTunnel1
ip address 1.1.1.2 255.255.255.255
pim sm
#
bgp 100
#
ipv4-family unicast
peer VPN-G enable
peer 1.1.1.1 enable
peer 1.1.1.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer VPN-G enable
peer 1.1.1.1 enable
peer 1.1.1.3 enable
#
import-route rip 2
import-route direct
#
ipv4-family vpn-instance BLUE
import-route rip 3

import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.2 0.0.0.0
network 192.168.0.0 0.0.255.255
#
network 10.0.0.0
#
rip 3 vpn-instance BLUE
network 10.0.0.0
#
return
l Configuration file of PE-C
#
sysname PE-C
#
router id 1.1.1.3
#
#
mpls lsr-id 1.1.1.3
mpls
#
mpls ldp
#
ip vpn-instance RED
#
ip vpn-instance BLUE
#
interface Vlanif100
ip address 192.168.7.1 255.255.255.0
pim sm
mpls
mpls ldp
#
interface Vlanif110
ip address 10.110.5.1 255.255.255.0
pim sm
#
interface Vlanif120
ip address 10.110.6.1 255.255.255.0
pim sm
#
#
#


#
#
interface LoopBack1
ip address 1.1.1.3 255.255.255.255
pim sm
#
interface LoopBack2
ip address 33.33.33.33 255.255.255.255
pim sm
#
pim vpn-instance BLUE
c-bsr LoopBack2
c-rp LoopBack2
#
interface MTunnel0
ip address 1.1.1.3 255.255.255.255
pim sm
#
interface MTunnel1
ip address 1.1.1.3 255.255.255.255
pim sm
#
bgp 100
#
ipv4-family unicast
peer VPN-G enable
peer 1.1.1.1 enable
peer 1.1.1.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer VPN-G enable
peer 1.1.1.1 enable
peer 1.1.1.2 enable
#
import-route rip 2
import-route direct
#
ipv4-family vpn-instance BLUE
import-route rip 3
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.3 0.0.0.0
network 192.168.0.0 0.0.255.255
#
network 10.0.0.0


#
rip 3 vpn-instance BLUE
network 10.0.0.0
#
return
l Configuration file of P
#
sysname P
#
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
interface Vlanif10
ip address 192.168.6.2 255.255.255.0
pim sm
mpls
mpls ldp
#
interface Vlanif20
ip address 192.168.7.2 255.255.255.0
pim sm
mpls
mpls ldp
#
interface Vlanif30
ip address 192.168.8.2 255.255.255.0
pim sm
mpls
mpls ldp
#
#
#
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
pim sm
#
pim
c-bsr Loopback1
c-rp Loopback1
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 192.168.0.0 0.0.255.255
#
return
l Configuration file of CE-Ra
#
sysname CE-Ra
#
#

interface Vlanif130
ip address 10.110.7.1 255.255.255.0
pim sm
#
interface Vlanif140
ip address 10.110.2.2 255.255.255.0
pim sm
#
#
#
rip 2
network 10.0.0.0
import-route direct
#
return
l Configuration file of CE-Bb
#
sysname CE-Bb
#
#
interface Vlanif150
ip address 10.110.8.1 255.255.255.0
pim sm
#
interface Vlanif160
ip address 10.110.3.2 255.255.255.0
pim sm
#
#
#
rip 3
network 10.0.0.0
import-route direct
#
return
l Configuration file of CE-Rb
#
sysname CE-Rb
#
#
interface Vlanif170
ip address 10.110.9.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif180
ip address 10.110.4.2 255.255.255.0
pim sm
#
interface Vlanif190
ip address 10.110.12.1 255.255.255.0
pim sm
#


#
#
#
interface loopback 1
ip address 22.22.22.22 32
pim sm
#
pim
c-bsr Loopback1
c-rp Loopback1
#
rip 2
network 10.0.0.0
network 22.0.0.0
import-route direct
#
return
l Configuration file of CE-Rc
#
sysname CE-Rc
#
#
interface Vlanif200
ip address 10.110.10.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif210
ip address 10.110.5.2 255.255.255.0
pim sm
#
interface Vlanif220
ip address 10.110.12.2 255.255.255.0
pim sm
#
#
#
#
#
rip 2
network 10.0.0.0
import-route direct
#
return
l Configuration file of CE-Bc
#
sysname CE-Bc
#
#

interface Vlanif230
ip address 10.110.11.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif240
ip address 10.110.6.2 255.255.255.0
pim sm
#
#
#
rip 3
network 10.0.0.0
import-route direct
#
return

Configuration Guide - Multicast 9 IPv4 Multicast Routing Management
9 IPv4 Multicast Routing Management
About This Chapter
The system synchronously maintains multiple multicast routing protocols, and controls multicast
routing and forwarding through the information exchanged between the control plane and the
forwarding plane.
9.1 Overview of IPv4 Multicast Routing Management
Multicast routing and forwarding maintains a protocol routing table, multicast routing table, and
multicast forwarding table. A multicast routing protocol creates multicast routing entries through
RPF.
9.2 IPv4 Multicast Routing Management Features Supported by the S9300
The IPv4 multicast routing management features supported by the system are: static multicast
route, GRE tunnel, multicast routing policy, controlling the multicast forwarding range,
controlling the capacity of a multicast forwarding table, testing multicast routes, and multicast
splitting.
9.3 Configuring a Static Multicast Route
Static multicast routes have the functions of changing RPF routes and connecting RPF routes.
9.4 Configuring the Multicast Routing Policy
Configuring a multicast routing policy involves configuring the longest match of the multicast
route, configuring multicast load splitting, and setting a multicast load splitting weight.
9.5 Configuring the Multicast Forwarding Scope
Multicast information of each multicast group in a network should be transmitted within a certain
range. Therefore, configuring a multicast forwarding boundary are necessary for restricting the
multicast data forwarding scope.
9.6 Configuring Control Parameters of the Multicast Forwarding Table
During network planning, you can restrict the capacity of the forwarding table on a multicast
device, such as the maximum number of entries in the multicast forwarding table and the
maximum number of downstream interfaces of multicast forwarding entries. In this manner,
traffic load on the multicast device is released and the fault risk resulted from excessive entries
can be avoided.
9.7 Maintaining the Multicast Policy

Maintaining IPv4 multicast routing management involves testing multicast routing, checking
the RPF path and multicast path, clearing multicast forwarding and routing entries, and
monitoring multicast routing and forwarding.
Examples for configuring static multicast routes and multicast load splitting are provided.


Multicast routing and forwarding maintains a protocol routing table, multicast routing table, and
multicast forwarding table. A multicast routing protocol creates multicast routing entries through
RPF.
In the S9300, multicast routing and forwarding consist of the following three aspects:
l Each multicast routing protocol has its routing table, such as PIM routing table.
l The multicast routing information of each multicast routing protocol forms a general
multicast routing table.
The multicast routing table resides in the multicast route management module. It is
composed of (S, G) entries. (S, G) indicates that S sends multicast data to G. If the multicast
route management module supports multiple multicast protocols, the routing table contains
multicast routes that are generated by the protocols. The routing entries are copied to the
forwarding table.
l The multicast forwarding table controls the forwarding of multicast data packets.
The multicast forwarding table guides the forwarding of multicast data packets. It remains
consistent with the multicast routing table.
To ensure that multicast data is transmitted along the correct path, multicast routing protocols
use the Reverse Path Forwarding (RPF) to create multicast routing entries.
The system performs RPF check based on the following types of routes:
l Unicast routes
The unicast routing table collects the shortest paths to each destination.
l MBGP routes
The MBGP routing table provides multicast routing information.
l MIGP routes
The MIGP routing table provides the routing information calculated based on physical
interfaces of the TE tunnel to guide the forwarding of multicast packets.
l Static multicast routes
The static multicast routing table provides RPF routing information that is specified through
static configuration.
9.2 IPv4 Multicast Routing Management Features

Supported by the S9300
The IPv4 multicast routing management features supported by the system are: static multicast
route, GRE tunnel, multicast routing policy, controlling the multicast forwarding range,
controlling the capacity of a multicast forwarding table, testing multicast routes, and multicast
splitting.

Static Multicast Route

The static multicast route is an important factor of RPF check. By configuring the static multicast
route, users can specify the RPF interface and RPF neighbor for a specific source of packets on
the current switch.
The static multicast route cannot be used to forward data. It only affects RPF check, and is also
called static RPF route.
The static multicast route is valid only on the configured multicast switchs, and cannot be
advertised or imported to other switchs.
Multicast Routing Policy

If multiple unicast routes with the same cost exist when a multicast switch selects an upstream
interface, users can use one of following methods to configure the switch to select the RPF route:
l By default, the switch chooses the route with the largest next-hop address.
l According to the longest match, the switch selects the route longest matching the address
of the source of the packet.
l Load splitting is configured among equal-cost routes. Performing load splitting of multicast
traffic according to different policies can optimize network traffic transmission in the
scenario where multiple multicast data flows exist.
There are five multicast load splitting policies: stable-preferred, balance-preferred, source
address-based, group address-based, and source and group addresses-based. The five load
splitting policies are mutually exclusive. In stable-preferred mode and balance-preferred
mode, you can configure load splitting weights on the interfaces to achieve unbalanced
multicast load splitting.
Controlling the Multicast Forwarding Range

In a network, the multicast information to which each multicast group corresponds is transmitted
in a certain range. Users can define the multicast forwarding range by using the following
method:
l Configuring a multicast forwarding boundary on an interface to form a closed multicast
forwarding area.
Controlling the Capacity of a Multicast Forwarding Table

When planning a specific network according to network services, the Internet Service Provider
(ISP) can perform the following configurations:
l Limiting the number of entries in the multicast forwarding table
Each switch maintains a forwarding entry for each received multicast packet. Too many
multicast forwarding entries, however, use up the memory of a switch. Users can define
the maximum number of entries in the multicast forwarding table of a switch. Limiting the
number of entries according to the actual networking and service performance can avoid
switch faults caused by excessive entries.
l Limiting the number of downstream nodes of each forwarding entry
Switch replicate a multicast packet for each downstream node, and then send it out. Each
downstream node forms a branch of an MDT. The number of downstream nodes determines
the maximum scale of the MDT and the multicast service range. Users can define the

number of downstream nodes of a single forwarding entry. Limiting the number of

downstream nodes according to the actual networking and service performance can reduce
the processing pressure of a switch and control the multicast service range.
Testing Multicast Routing

When a fault occurs on a multicast network, you can run the ping multicast and mtrace
commands to test the connectivity of the network.
NOTE
The mtrace command can be used to trace multicast path on a specified multicast VPN network to maintain
multicast VPN services and locate faults on the network.
The ping multicast command is used to check whether a group is reachable and to implement
the following functions:
l Pinging a reserved group address
This is used to check whether a member of a group exists in the directly connected network
segment, and is not exclusive for multicast networks. You can ping devices that use
multicast addresses.
l Pinging a common group address
This function is applied as follows:
– To generate multicast traffic and trigger the creation of multicast routing entries: Based
on multicast routing information, you can check whether a protocol runs normally,
determine whether the network can carry multicast services, or test the forwarding
performance.
– To check the members of related groups in the network: Based on the ICMP-Echo-
Reply messages received from destination hosts, the switch on which the command is
used checks the members of the groups in the network, and calculates response time
and the TTL from the switch to members. You can run the command repeatedly in a
certain interval to calculate the network delay and route flapping.
The mtrace command can be used to trace the following paths and output the hop information:
l RPF path from a source to a querier
l Multicast path from a source to a querier
l RPF path from a source to a destination host
l Multicast path from a source to a destination host
NOTE
You can ping multicast addresses by using the Network Quality Analysis (NQA) test instances or related
commands. For detailed configurations of NQA test instances, refer to the chapter " NQA Configuration
" in Quidway S9300 Terabit Routing Switch Configuration Guide - Network Management.
9.3 Configuring a Static Multicast Route

Static multicast routes have the functions of changing RPF routes and connecting RPF routes.


Before configuring static multicast routes, familiarize yourself with the applicable environment,
pre-configuration tasks, and required data. This can help you complete the configuration task
quickly and accurately.
Static multicast route has the following functions:
l Changing RPF route
If the topology of multicast is the same as that of unicast, the transmission path of multicast
data is the same as that of unicast data. Users can change the RPF route by configuring a
static multicast route. Thus a transmission path of the multicast data, which is different
from the transmission path of unicast data, is established.
l Connecting RPF route
In the network segment where unicast routes are blocked, when multicast static routes are
not configured, packets cannot be forwarded because there is no RPF route. You can
configure multicast static routes. Therefore, the system can generate RPF routes, complete
RPF check, create routing entries, and guide the forwarding of packets.
Before configuring a static multicast route, complete the following tasks:
l Configuring basic multicast functions
Data Preparation
To configure a static multicast route, you need the following data.
No. Data
1 Multicast source address, mask or mask length
2 Unicast routing protocol
3 Filtering policy and its preference
9.3.2 Configuring a Static Multicast Route

When configuring a static multicast route, you can specify an RPF interface and an RPF neighbor
on the current multicast device.

Context
CAUTION
When configuring a static multicast route, configure the outgoing interface through the command
if the next hop is in the point-to-point format. If the next hop is not in the point-to-point format,
you must use the next hop.
Do as follows on the multicast switch:
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip rpf-route-static [ vpn-instance vpn-instance-name ] source-address { mask | mask-
length } [ isis process-id | ospf process-id | rip process-id | bgp | static ]
[ route-policy route-policy-name ] { interface-type interface-number }
[ preference preference ] [ order order-number ]
A static multicast route is configured.
l source-address { mask |mask-length }: specifies a source address and mask.

l isis process-id, ospf process-id, rip process-id, bgp, static: specifies that the matching route
must be present in the specified unicast routing protocol. protocol specifies a unicast routing
protocol. process-id specifies the ID of a process.
l route-policy policy-name: specifies the matching rule of the static multicast route.
l interface-type interface-number: specifies the type and the number of the outgoing interface.
The outgoing interface acts as the RPF interface.
l preference preference: specifies the preference of the route. The greater the preference value
is, the lower the preference is.
l order order-num: specifies the configuration order of routes on the same network segment.
----End

After static multicast routes are configured, you can check the static multicast routing table and
RPF routing information to ensure the normal running of the multicast network.
Procedure
l Run the display multicast routing-table [ vpn-instance vpn-instance-name ] static
[ config ] [ source-address { mask | mask-length } ] command to check the static multicast
routing table.

l Run the display multicast [ vpn-instance vpn-instance-name | all-instance ] rpf-info

source-address [ group-address ] [ rpt | spt ] command to check RPF routing information
of a specified multicast source.
----End
9.4 Configuring the Multicast Routing Policy

Configuring a multicast routing policy involves configuring the longest match of the multicast
route, configuring multicast load splitting, and setting a multicast load splitting weight.

Before configuring multicast routing policies, familiarize yourself with the applicable
If multiple equal-cost unicast routes exist when a multicast switch select an upstream interface,
you can configure the switch to the RPF switch by using one of the following methods:
l By default, the switch chooses the route with the largest next-hop address.
l According to the longest match rules, you can configure the switch to select the route with
the destination address that longest matches the address of the source of the packet.
l You can configure load splitting among these switchs. Performing load splitting of
multicast traffic according to different policies can optimize network traffic when multiple
multicast data flows exist.
Before configuring the multicast routing policy, complete the following tasks:

Data Preparation
To configure the multicast routing policy, you need the following data.
No. Data
1 Multicast load splitting policy
2 Multicast load splitting weight on the interface
9.4.2 Configuring Longest Match of Multicast Route

If the longest match principle is configured for route selection, a multicast device prefers the
route with the longest matched mask. If the mask lengths of multiple routes are the same, the

device selects a route as the multicast data forwarding path in the order of the static route, inter-
domain unicast route, and intra-domain unicast route.
Context
CAUTION
Configurations related to VPN instances are applicable only to the PE switch. When configuring
the longest match of multicast routes for a VPN instance on a PE, perform the configuration in
the VPN instance. In other cases, the longest match is configured in the public network instance.
By default, routes are selected in the order of routing entries.
Procedure
l Public network instance
1. Run:
system-view

2. Run:
multicast longest-match
Devices are selected according to the longest match.

l VPN instance
1. Run:
system-view

2. Run:

3. Run:
multicast longest-match
Devices are selected according to the longest match.
----End
9.4.3 Configuring Multicast Load Splitting

The multicast load splitting function extends multicast routing rules, which does not fully depend
on the RPF check. Performing load splitting of multicast traffic according to different policies
can optimize network traffic transmission in the scenario where multiple multicast data flows
exist. You can choose to configure a balance-preferred or stable-preferred load splitting policy.

Context
CAUTION
load splitting among multicast routes for a VPN instance on a PE, perform the configuration in
the VPN instance. In other cases, load balancing among multicast routes is configured in the
public network instance.
on the RPF check. If multiple equal-cost optimal routes exist over the network, they all can be
used for multicast data forwarding and multicast traffic is load split among multiple equal-cost
routes.
By default, load splitting is not performed.
Do as follows on the multicast router switch:
Procedure
1. Run:
system-view

2. Run:
multicast load-splitting { balance-preferred | stable-preferred | source
| group | source-group }
Multicast load balancing is configured. The parameters of the command are explained
as follows:
– balance-preferred: indicates balance-preferred load splitting. This policy is

applicable to the scenario where hosts frequently join or leave the groups, which
requires automatic load adjustment.
If balance-preferred is specified, the switch automatically adjusts and balances
the entries on the equal-cost routes when equal-cost routes are added or deleted,
IPv4 multicast routing entries are deleted, or IPv4 load splitting weights on the
interfaces are changed.
– stable-preferred: indicates stable-preferred load splitting. This policy is
applicable to the stable multicast networking.
If stable-preferred is specified, the switch automatically adjusts and balances the
entries when equal-cost routes are added or deleted; however, when IPv4 multicast
routing entries are deleted or load splitting weights on the interfaces are changed,
the switch does not automatically adjust the entries on the equal-cost routes.
– group: indicates group address-based load splitting. This policy is applicable to
the scenario of one source to multiple groups.
– source: indicates source address-based load splitting. This policy is applicable to
the scenario of one group to multiple sources.

– source-group: indicates source and group addresses-based load splitting. This

policy is applicable to the scenario of multiple sources to multiple groups.
NOTE
It is recommended to adopt a fixed IPv4 multicast load splitting policy based on the actual
networking. It is recommended to use the balance-preferred or stable-preferred policy.
balance-preferred or stable-preferred cannot be configured on the interface enabled with
PIM-DM.
You can configure a multicast load splitting weight only in a stable-preferred load splitting or
balance-preferred load splitting scenario.
3. (Optional) Run:

4. (Optional) Run:
multicast load-splitting weight weight-value
The multicast load splitting weight is set on the interface.

By default, the multicast load splitting weight of an interface is 1.
The greater the multicast load splitting weight of an interface, the more multicast
routing entries with this interface being the upstream interface. When the multicast
load splitting weight on an interface is 0, it indicates that the routes with this interface
being the upstream interface do not take part in load splitting.
l VPN instance
1. Run:
system-view

2. Run:

3. Run:
multicast load-splitting { balance-preferred | stable-preferred | source
| group | source-group }
Multicast load splitting is configured.
NOTE
You can configure a multicast load splitting weight only in a stable-preferred load splitting or
balance-preferred load splitting scenario.
4. (Optional) Run:

The interface can be a VLANIF interface, or POS interface.
5. (Optional) Run:

The greater the multicast load splitting weight of an interface, the more multicast
routing entries with this interface being the upstream interface. When the multicast
load splitting weight on an interface is 0, it indicates that the routes with this interface
being the upstream interface do not take part in load splitting.
----End
9.4.4 Configuring a Multicast Load Splitting Weight

When a load splitting policy is configured, because the forwarding capabilities of equal-cost
routes are different from the actual load bearing situation on the equal-cost routes, balanced load
splitting cannot meet network requirements in some scenarios. In such a case, you can configure
a load splitting weight on an interface to achieve unbalanced multicast load splitting.
Context
When stable-preferred or balance-preferred load splitting is configured, because the forwarding
capabilities of equal-cost routes are different from the actual load bearing situation on the equal-
cost routes, balanced load splitting cannot meet network requirements in some scenarios. In such
a case, you can configure a load splitting weight on an interface to achieve unbalanced multicast
load splitting.
Do as follows on the switch enabled with multicast:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Trunk interface.
The greater the multicast load splitting weight of an interface, the more multicast routing entries
with this interface being the upstream interface. When the multicast load splitting weight on an
interface is 0, it indicates that the routes with this interface being the upstream interface do not
take part in load splitting.
Step 3 Run:
----End


After multicast routing policies are configured, you can check the multicast routing table and
RPF routing information to ensure normal running of the multicast network.
Procedure
l Run the following commands to check the multicast routing table.
– display multicast { vpn-instance vpn-instance-name | all-instance } routing-table
[ group-address [ mask { group-mask | group-mask-length } ] | source-address
[ mask { source-mask | source-mask-length } ] | incoming-interface { interface-type
interface-number | register } | outgoing-interface { include | exclude | match }
{ interface-type interface-number | register | none } ] * [ outgoing-interface-
number [ number ] ]
– display multicast routing-table [ group-address [ mask { group-mask | group-mask-
length } ] | source-address [ mask { source-mask | source-mask-length } ] | incoming-
instance-name | register | none } ] * [ outgoing-interface-number [ number ] ]
l Run the following command to check the source-specific RPF route.
display multicast [ vpn-instance vpn-instance-name | all-instance ] rpf-info source-
address [ group-address ] [ rpt | spt ]
----End
9.5 Configuring the Multicast Forwarding Scope

range. Therefore, configuring a multicast forwarding boundary are necessary for restricting the
multicast data forwarding scope.
9.5.1 Establish the Configuration Task

Before configuring the multicast data forwarding scope, familiarize yourself with the applicable
Multicast information to which each multicast group corresponds is forwarded in a certain scope
in network. Uers can define the multicast forwarding scope by using the following methods:
l Configuring the multicast forwarding boundary to form a close multicast forwarding area.
The interface configured with a forwarding boundary of a multicast group cannot send or
receive packets of the multicast group.
Before configuring the multicast forwarding scope, complete the following tasks:

Data Preparation
To configure the multicast forwarding scope, you need the following data.
No. Data
1 Group address, mask, and mask length of the multicast forwarding boundary
9.5.2 Configuring the Multicast Forwarding Boundary

When an interface of a multicast device is configured with a forwarding boundary for a specified
group, the forwarding scope of multicast packets is restricted.
Context
By default, no multicast forwarding boundary is configured on the interface.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Trunk interface.
Step 3 Run:
multicast boundary group-address { mask | mask-length }
The multicast forwarding boundary is configured.
----End

After the multicast forwarding scope is configured, you can check information about the
multicast routing table and multicast boundary of an interfaceto ensure normal running of the
multicast network.
Procedure
l Run the following commands to check the multicast routing table.


number [ number ] ]
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 of an interface.
----End
9.6 Configuring Control Parameters of the Multicast

Forwarding Table
traffic load on the multicast device is released and the fault risk resulted from excessive entries
can be avoided.

Before configuring control parameters for the multicast forwarding table, familiarize yourself
with the applicable environment, pre-configuration tasks, and required data. This can help you
complete the configuration task quickly and accurately.
To plan a network according to the services, the ISP needs to perform the following configuration
policies:
l Limiting the number of entries in the multicast forwarding table

Each switch maintains a routing entry for each received multicast packet. Too many entries,
however, may exhaust the memory of the switch. In this case, you can define the maximum
number of multicast routing entries. Limiting the number of the entries can avoid faults in
the switch.
l Limiting the number of downstream nodes of a single entry
Switchs copy a multicast packet for each downstream node, and the downstream node sends
the copy out. Each downstream node forms a branch of the multicast distribution tree. The
number of the downstream nodes determines the maximum scale of the multicast
distribution tree and the multicast service scope. Users can define the number of the
downstream nodes of a single forwarding entry. Limiting the number of downstream nodes
according to the actual networking and the services can reduce the pressure of switchs and
control the multicast service scope.

Before configuring control parameters of the multicast forwarding table, complete the following
tasks:
Data Preparation
To configure control parameters of the multicast forwarding table, you need the following data.
No. Data
1 Multicast source address, group address, and mask or mask length
2 Matching policy, switch sequence, and route preference of the multicast routes
3 Maximum number of entries in the multicast forwarding table
4 Maximum number of downstream nodes of each entry in the multicast forwarding

table
9.6.2 Setting the Maximum Number of Entries in Multicast

Forwarding Table
Too many multicast forwarding entries may use up the memory of a multicast device. You can
set the maximum number of entries in a multicast forwarding table of a multicast device and
adjust the number of entries according to the actual networking and service performance to avoid
the fault risk resulted from excessive entries.
Context
CAUTION
the maximum number of entries in the forwarding table for a VPN instance on a PE, perform
the configuration in the VPN instance. In other cases, the maximum number of entries in the
forwarding table is configured in the public network instance.
By default, the maximum number supported by the system is used.

Procedure
1. Run:
system-view


2. Run:
multicast forwarding-table route-limit limit
The maximum number of entries in the multicast forwarding table is configured.

l VPN instance
1. Run:
system-view

2. Run:

3. Run:
multicast forwarding-table route-limit limit
The maximum number of entries in the multicast forwarding table is configured.

----End
9.6.3 Setting the Maximum Number of Downstream Nodes of

Multicast Forwarding Entry
A multicast device replicates a copy of multicast packets for each downstream interface. Then,
you can set the number of downstream interfaces of a single forwarding entry and adjust the
number of downstream interfaces according to the actual networking and service performance
to release the burden on the multicast device.
Context
CAUTION
This configuration becomes valid only after the reset multicast forwarding-table command is
used. Multicast services are interrupted after you run the reset multicast forwarding-table
command. So, confirm the action before you use the command.
Configurations related to the VPN instance are applicable only to the PE switch. When
configuring the maximum number of downstream nodes for a forwarding entry in a VPN instance
on a PE, perform the configuration in the VPN instance. In other cases, the maximum number
of entries in the forwarding table is configured in the public network instance.
Procedure
1. Run:
system-view

2. Run:
multicast forwarding-table downstream-limit limit
The maximum number of downstream nodes of a forwarding entry in the multicast

forwarding table is configured.
The maximum number is valid when it is smaller than the default value.
l VPN instance
1. Run:
system-view

2. Run:

3. Run:
multicast forwarding-table downstream-limit limit
The maximum number of downstream nodes of a forwarding entry in the multicast

forwarding table is configured.
----End

After control parameters for the multicast forwarding table are configured, you can check
information about the multicast routing table to ensure normal running of the multicast network.
Procedure
l Run the display multicast [ vpn-instance vpn-instance-name | all-instance ] forwarding-
table [ group-address [ mask { group-mask | group-mask-length } ] | source-address
interface-number | register } | outgoing-interface { include | exclude | match } { interface-
type interface-number | register | none } | statistics ] * command to check the multicast
forwarding table.
----End
9.7 Maintaining the Multicast Policy

Maintaining IPv4 multicast routing management involves testing multicast routing, checking
the RPF path and multicast path, clearing multicast forwarding and routing entries, and
monitoring multicast routing and forwarding.
9.7.1 Testing Multicast Routing

When a fault occurs during multicast data transmission, you can run the ping command to check
the RPF path and multicast path.

Context
When data transmission is abnormal, you can ping related multicast addresses to check the
multicast routing.
Procedure
l Run the ping multicast [ -i interface-type interface-number | -c count | -h ttl-value | -m
time | -p pattern | -q | -s packet(s)ize | -t timeout | -tos tos-value | -v ] * host command in
any view to ping a reserved group address.
l Run the ping multicast [ -c count | -h ttl-value | -m time | -p pattern | -q | -s packet(s)ize |
-t timeout | -tos tos-value | -v ] * host command in any view to ping a common group address.
----End
9.7.2 Check RPF Paths and Multicast Paths

When a fault occurs during multicast data transmission, you can run the mtrace command to
check the RPF path and multicast path.
Context
NOTE
When checking the RPF path or multicast path from a source to a destination host, run the mtrace query-
policy [ acl-number ] command on the switch connected to hosts to configure the filtering policy for
queriers. The ACL defines the address scope of reliable queriers. Based on the ACL, the last-hop switch
refuses the IGMP-Tracert-Query messages sent by illegal queriers. Note the following when using this
command:
l This command is valid only for the last-hop switch, and the querier is not the last-hop switch.
l This command is used to filter only the IGMP-Tracert-Query message encapsulated in a unicast IP
packet.
l This command is not applicable to the trace that is initiated by the local querier.
When a fault occurs during data transmission, you can run the following commands in any view
to check RPF paths and multicast paths.
Procedure
l Run the mtrace [ -ur resp-dest | -l [ stat-times ] [ -st stat-int ] | -m max-ttl | -q nqueries | -
ts ttl | -tr ttl | -v | -w timeout | -vpn-instance vpn-name ] * source source-address command
in any view to check the RPF path from a source to a querier.
l Run the mtrace -g group [ { -mr | -ur resp-dest } | -l [ stat-times ] [ -st stat-int ] | -m max-
ttl | -q nqueries | -ts ttl | -tr ttl | -v | -w timeout | -vpn-instance vpn-name ] * source source-
address command in any view to check the multicast path from a source to a querier.
l Run the mtrace { -gw last-hop-router | -d } -r receiver [ -ur resp-dest | -a source-ip-
address | -l [ stat-times ] [ -st stat-int ] | -m max-ttl | -q nqueries | -ts ttl | -tr ttl | -v | -w
timeout | -vpn-instance vpn-name ] * source source-address command in any view to
check the RPF path from a source to a destination host.
l Run the mtrace { -gw last-hop-router | -b | -d } -r receiver -g group [ { -mr | -ur resp-
dest } | -a source-ip-address | -l [ stat-times ] [ -st stat-int ] | -m max-ttl | -q nqueries | -ts
ttl | -tr ttl | -v | -w timeout | -vpn-instance vpn-name ] * source source-address command
in any view to check the multicast path from a source to a destination host.
----End

9.7.3 Clearing Multicast Routing and Forwarding Entries

After you confirm to clear multicast forwarding and routing entries, use the reset command in
the user view. After you run the reset command to clear information in the multicast forwarding
table and the multicast routing table, multicast data cannot be normally transmitted. So, confirm
the action before you use the command.
Context
CAUTION
The reset command clears the entries in the multicast forwarding table or the multicast routing
table. It may result in abnormal multicast information forwarding. After the routing entries in
the multicast routing table are cleared, the corresponding forwarding entries corresponding to
the public network instance or VPN instance are also cleared. So, confirm the action before you
use the command.
Procedure
l Run the following commands to clear the forwarding entries in the multicast forwarding
table.
– reset multicast [ vpn-instance vpn-instance-name | all-instance ] forwarding-table
all
– reset multicast [ vpn-instance vpn-instance-name | all-instance ] forwarding-table
{ group-address [ mask { group-mask | group-mask-length } ] | source-address
interface-number | register } } *
l Run the following commands to clear the routing entries in the multicast routing table.
– reset multicast [ vpn-instance vpn-instance-name | all-instance ] routing-table all
– reset multicast [ vpn-instance vpn-instance-name | all-instance ] routing-table
{ group-address [ mask { group-mask | group-mask-length } ] | source-address
interface-number | register } } *
----End
9.7.4 Monitoring the Status of Multicast Routing and Forwarding

During the routine maintenance of IPv4 multicast routing management, you can run the display
commands in any view to know the running of the multicast forwarding table and routing table.
Context
In routine maintenance, you can run the following commands in any view to check the status of
multicast routing and forwarding.

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 in any view to check the multicast boundary configured on an interface.
l Run thedisplay multicast [ vpn-instance vpn-instance-name | all-instance ] forwarding-
table [ group-address [ mask { group-mask | group-mask-length } ] | source-address
interface-number | register } | outgoing-interface { include | exclude | match } { interface-
type interface-number | register | none } | statistics ] * command in any view to check the
multicast forwarding table.
l Run the following commands in any view to check the multicast routing table.
number [ number ] ]
l Run the display multicast routing-table [ vpn-instance vpn-instance-name ] static
[ config ] [ source-address { mask-length | mask } ] command in any view to check the
static multicast routing table.
l Run the display multicast [ vpn-instance vpn-instance-name | all-instance ] rpf-info
source-address [ group-address ] [ rpt | spt ] command in any view to check the RPF
routing information.
----End
9.7.5 Debugging Multicast Routing and Forwarding

When a fault occurs during IPv4 multicast routing management, run the debugging commands
Context
CAUTION
Debugging affects the performance of the system. After debugging, run the undo debugging
When a fault occurs when multicast is enabled, run the following debugging commands in the
user view to debug multicast routes and to locate the fault.

Procedure
l Run the following commands in the user view to enable the debugging of multicast
forwarding.
– debugging mfib [ vpn-instance vpn-instance-name | all-instance ] all
– debugging mfib [ vpn-instance vpn-instance-name | all-instance ] { no-cache |
module | packet | register | route | sync | upcall | wrong-iif } [ advanced-acl-
number ]
l Run the debugging mrm [ vpn-instance vpn-instance-name | all-instance ] { all | event |
packet [ advanced-acl-number ] | route [ advanced-acl-number ] } command in the user
view to enable the debugging of multicast routing management.
----End

Examples for configuring static multicast routes and multicast load splitting are provided.
9.8.1 Example for Changing Static Multicast Routes to RPF Routes
As shown in Figure 9-1, PIM-DM runs on the network and all the Switches support multicast.
The receiver can receive information from the multicast source. Switch A, Switch B, and Switch
C run OSPF. You need to configure a static multicast route to make the multicast path from the
source to the receiver different from the unicast path from the source to the receiver.

Figure 9-1 Networking diagram for changing static multicast routes to RPF routes
SwitchC
GE3/0/0 GE2/0/0
GE3/0/0 PIM-DM GE2/0/0
SwitchA SwitchB
GE1/0/0 GE1/0/0
GE2/0/0 GE3/0/0
8.1.1.2/24
7.1.1.2/24
Source Receiver
Multicast static route

Switch A GE 1/0/0 VLANIF 10 9.1.1.1/24
GE 2/0/0 VLANIF 20 8.1.1.1/24
GE 3/0/0 VLANIF 30 12.1.1.1/24
Switch B GE 1/0/0 VLANIF 10 9.1.1.2/24
GE 2/0/0 VLANIF 40 13.1.1.1/24
GE 3/0/0 VLANIF 50 7.1.1.1/24
Switch C GE 2/0/0 VLANIF 40 13.1.1.2/24
GE 3/0/0 VLANIF 30 12.1.1.2/24
1. Configure the IP addresses of interfaces and the unicast routing protocol on each Switch.
2. Enable the multicast function on all Switches, PIM-SM on all interfaces, and IGMP on the
interfaces at the host side.
3. Configure static multicast RPF routes on Switch B, and configure Switch C as the RPF
neighbor.
Data Preparation
l IP address of the source

l Outgoing interface of the route from Switch B to Switch C: VLANIF 40

NOTE
This configuration example describes only the commands used to configure static multicast routes.
Procedure
# Configure the IP addresses and masks on the interfaces on each Switch according to Figure
9-1. IP addresses must be configured on the VLANIF interfaces. OSPF runs between Switch A,
Switch B and Switch C, and the Switches can update routes among them through the unicast
routing protocol. The configuration procedure is not provided here.
Step 2 Enable multicast on all Switches and PIM-DM on all interfaces.
# Enable multicast on all Switches, and PIM-SM on all interfaces. Enable the IGMP function
on the interfaces at the host side. The configurations of other Switches are similar to
configuration of Switch B, and are not provided here.
[SwitchB-Vlanif10] pim dm
[SwitchB-Vlanif50] igmp enable
# Run the display multicast rpf-info command on Switch B to view the RPF information of
the source. The RPF routes are unicast routes, and the RPF neighbor is Switch A. The following
information is displayed:
[SwitchB] display multicast rpf-info 8.1.1.2
RPF information about source 8.1.1.2:
RPF interface: vlanif10, RPF neighbor: 9.1.1.1
Referenced route/mask: 8.1.1.0/24
Referenced route type: unicast
Route selection rule: preference-preferred
Load splitting rule: disable
Step 3 Configure the static multicast route.
# Configure a static multicast RPF route on Switch B, and configure Switch C as the RPF
neighbor.
[SwitchB] ip rpf-route-static 8.1.1.0 255.255.255.0 13.1.1.2
# Run the display multicast rpf-info command on Switch B to view the RPF information of
the source. The RPF information is as follows. The RPF routes and the RPF neighbor are updated
according to the static multicast route.
Referenced route type: mstatic


----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20 30
#
#
interface Vlanif10
ip address 9.1.1.1 255.255.255.0
pim dm
#
interface Vlanif20
ip address 8.1.1.1 255.255.255.0
pim dm
#
interface Vlanif30
ip address 12.1.1.1 255.255.255.0
pim dm
#
#
#
#
ospf 1
area 0.0.0.0
network 8.1.1.0 0.0.0.255
network 9.1.1.0 0.0.0.255
network 12.1.1.0 0.0.0.255
#
return

#
sysname SwitchB
#
vlan batch 10 40 50
#
#
interface Vlanif10
ip address 9.1.1.2 255.255.255.0
pim dm
#
interface Vlanif40
ip address 13.1.1.1 255.255.255.0
pim dm
#
interface Vlanif50
ip address 7.1.1.1 255.255.255.0
pim dm
igmp enable
#

#
#
#
ospf 1
area 0.0.0.0
network 7.1.1.0 0.0.0.255
network 9.1.1.0 0.0.0.255
network 13.1.1.0 0.0.0.255
#
ip rpf-route-static 8.1.1.0 255.255.255.0 13.1.1.2
#
return
l Configuration file of Switch C

#
sysname SwitchC
#
vlan batch 30 40
#
#
interface Vlanif30
ip address 12.1.1.2 255.255.255.0
pim dm
#
interface Vlanif40
ip address 13.1.1.2 255.255.255.0
pim dm
#
#
#
ospf 1
area 0.0.0.0
network 12.1.1.0 0.0.0.255
network 13.1.1.0 0.0.0.255
#
return
9.8.2 Example for Connecting RPF Routes Through Static Multicast

Routes
As shown in Figure 9-2, PIM-DM runs on the network and all Switch support multicast. The
receiver can receive information from the multicast source Source1. Switch B and Switch C run
OSPF. No unicast route is available between Switch A and Switch B. You need to use a multicast
static route to enable the receiver to receive information sent by Source2.

Figure 9-2 Networking diagram for connecting the RPF route through static multicast routes
OSPF PIM-DM
Source1
10.1.3.2/24
GE2/0/0 SwitchA
GE3/0/0 GE3/0/0
SwitchB
GE1/0/0 GE1/0/0
GE1/0/0
SwitchC
Source2
GE2/0/0 10.1.5.2/24
Receiver
Multicast static route

Switch A GE 1/0/0 VLANIF 11 10.1.5.1/24
GE 3/0/0 VLANIF 40 10.1.4.2/24
Switch B GE 1/0/0 VLANIF 20 10.1.2.2/24
GE 2/0/0 VLANIF 13 10.1.3.1/24
GE 3/0/0 VLANIF 40 10.1.4.1/24
Switch C GE 1/0/0 VLANIF 20 10.1.2.1/24
GE 2/0/0 VLANIF 12 10.1.1.1/24
1. Configure the IP addresses of interfaces and the unicast routing protocol on each Switch.
2. Enable the multicast function on all routers, PIM-SM on all interfaces, and IGMP on the
interfaces connected to hosts.
3. Configure static multicast RPF routes on Switch B and Switch C.
Data Preparation
l IP address of Source2

l RPF interface, VLANIF 40, through which Switch B connects to Source 2 and the RPF
neighbor, namely, Switch A
l RPF interface, VLANIF 20, through which Switch C connects to Source 2 and the RPF
neighbor, namely, Switch C
NOTE
This configuration example describes only the commands used to configure static multicast routes.
Procedure
# Configure the IP addresses and masks on the interfaces on each Switch according to Figure
9-2. Switch B and Switch C belong to the same OSPF area, and they can update routes between
them through the unicast routing protocol. The configuration procedure is not provided here.
Step 2 Enable multicast on all Switches and PIM-DM on all interfaces.
# Enable multicast on all Switches, and PIM-DM on all interfaces. Enable the IGMP function
on the interfaces connected to hosts.
[SwitchA] interface vlanif11


[SwitchC-Vlanif20] pim dm
[SwitchC-Vlanif12] pim dm
# Source 1 (10.1.3.2/24) and Source 2 (10.1.5.2/24) send multicast data to the multicast group
G (225.1.1.1). The receiver joins multicast group G. Therefore, the receiver can receive 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 Switch B and Switch C. If no
information is displayed, it indicates that Switch B and Switch C have no RPF route to Source2.
Step 3 Configure the static multicast route.
# Configure a static multicast RPF route on Switch B, and configure Switch A as the RPF
neighbor.
[SwitchB] ip rpf-route-static 10.1.5.0 255.255.255.0 10.1.4.2

# Configure a static multicast RPF route on Switch C, and configure Switch B as the RPF
neighbor.
[SwitchC] ip rpf-route-static 10.1.5.0 255.255.255.0 10.1.2.2

# Run the display multicast rpf-info 10.1.5.2 command on Switch B and Switch C to view the
RPF information of Source2. The RPF information is as follows:
RPF information about: 10.1.5.2
Route selecting rule: preference-preferred
[SwitchC] display multicast rpf-info 10.1.5.2

# Run the display pim routing-table command on Switch C to view the routing table. Switch
C has the multicast entries of Source2. The receiver can receive the multicast data from Source2.
[SwitchC] display pim routing-table
(*, 225.1.1.1)
UpTime: 03:54:19
Upstream interface: NULL
1: vlanif12
(10.1.3.2, 225.1.1.1)
UpTime: 00:00:44
1: vlanif12
(10.1.5.2, 225.1.1.1)
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 dm
#
interface Vlanif40
ip address 10.1.4.2 255.255.255.0
pim dm
#
#
#
ospf 1
area 0.0.0.0
network 10.1.5.0 0.0.0.255
network 10.1.4.0 0.0.0.255
#
return

#
sysname SwitchB
#
vlan batch 13 20 40
#
#
interface Vlanif13
ip address 10.1.3.1 255.255.255.0
pim dm
#
interface Vlanif20
ip address 10.1.2.2 255.255.255.0
pim dm
#
interface Vlanif40
ip address 10.1.4.1 255.255.255.0
pim dm
#
#
#
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255

#
ip rpf-route-static 10.1.5.0 24 10.1.4.2
#
return

#
sysname SwitchC
#
vlan batch 12 20
#
#
interface Vlanif12
ip address 10.1.1.1 255.255.255.0
igmp enable
pim dm
#
interface Vlanif20
ip address 10.1.2.1 255.255.255.0
pim dm
#
#
#
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
#
ip rpf-route-static 10.1.5.0 24 10.1.2.2
#
return
9.8.3 Example for Configuring Multicast Load Splitting
RPF check is the basis of route selection and unicast routes are used to forward multicast traffic.
According to RPF check, a unique route is selected to forward multicast data. If multicast traffic
is heavy, network congestion may occur and multicast services are affected. Multicast load
splitting is an extension of the multicast route selection rule and is independent of RPF check.
If there are multiple optimal equal-cost routes on a network, they may be used to forward
multicast data. Multicast traffic can be load balanced amount multiple equal-cost routes.
Currently, multicast load splitting can be performed based on the source address, group address,
and source group address, without meeting requirements of load splitting in all the scenarios. If
multicast routing entries and network configurations are stable, RPF interfaces and RPF
neighbors in the entries remain unchanged. If a few multicast routing entries are used, traffic
among equal-cost routes may be distributed unevenly.
The stable-preferred multicast load splitting policy offsets the disadvantages of the preceding
load splitting policies. As shown in Figure 9-3, three equal-cost routes are available from Switch
E connected to HostA to the multicast source. The stable-preferred multicast load splitting policy
is configured on Switch E so that entries are evenly distributed to the three equal-cost routes.
Load splitting among equal-cost routes is implemented.

If forwarding capabilities or traffic congestion degrees of the three equal-cost routes of Switch
E are different, multicast entries cannot be load balanced. You need to configure uneven load
splitting on Switch E, set different load splitting routes for upstream interfaces, and change the
number of multicast entries on the equal-cost routes. In this manner, multicast entries on the
equal-cost routes can be controlled flexibly.
Figure 9-3 Networking diagram for configuring multicast load splitting
PIM-SM
Source
/0 GE GE1
GE1/0/0 E2/0/1 GE1/0 SwitchB 2/0/0 /0/1
G
GE2/0/2 GE1/0/2 GE2/0/0
GE2 GE1/0/0 GE2/0/0
/0/3 /0/3
SwitchA SwitchC GE1 SwitchE
GE1
/0/0 /0/0 HostA
GE2
Loopback0
SwitchD
Switch Interface IP Address Device Interface IP Address
Switch A GE1/0/0 10.110.1.2/24 Switch C GE1/0/0 192.168.2.2/24
VLANIF10 VLANIF70
GE2/0/1 192.168.1.1/24 GE2/0/0 192.168.5.1/24
VLANIF20 VLANIF80
GE2/0/2 192.168.2.1/24 Switch D GE1/0/0 192.168.3.2/24
VLANIF30 VLANIF90
GE2/0/3 192.168.3.1/24 GE2/0/0 192.168.6.1/24
VLANIF40 VLANIF100
LoopBack0 1.1.1.1/32 Switch E GE1/0/1 192.168.4.2/24
VLANIF110
SwitchB GE1/0/0 192.168.1.2/24 GE1/0/2 192.168.5.2/24
VLANIF50 VLANIF120
GE2/0/0 192.168.4.1/24 GE1/0/3 192.168.6.2/24
VLANIF60 VLANIF130
GE2/0/0 10.110.2.2/24
VLANIF140

l Assign IP addresses to interfaces on switches.
l Configure IS-IS to implement interworking among all the switches and ensure that route
costs are the same.
l Enable multicast on all the switches, enable PIM-SM on all the interfaces, and set the
loopback interface on Switch A as an RP.
l Configure stable-preferred multicast load splitting on Switch E to ensure the stability of
multicast services.
l HostA needs to receive data from some multicast groups for a long period. Add the host-
side interfaces of Switch E to multicast groups in batches.
l HostA needs to receive data from a new multicast group. According to networking
requirements, set different multicast load splitting weights for upstream interfaces on
Switch E to ensure that multicast traffic is distributed unevenly.
Data Preparation
l IP address of the multicast source
l IP addresses of interfaces on the switches
l Addresses of the multicast groups to which the host-side interfaces of Switch E are added
in batches
l Multicast load splitting weights of upstream interfaces on Switch E
Procedure
Step 1 Assign IP addresses to interfaces on the switches according to Figure 9-3. The configuration
details are not provided here.
Step 2 Configure IS-IS to implement interworking among switches and ensure that route costs are the
same. The configuration details are not provided here.
Step 3 Enable multicast on all the switches and enable PIM-SM on each interface.
# Configure Switch A. The configurations on Switch B, Switch C, Switch D, and Switch E are
similar to the configuration on Switch A, and are not provided here.
[SwitchA] interface Vlanif10

[SwitchA-LoopBack0] pim sm
[SwitchA-LoopBack0] quit
Step 4 Configure an RP on Switch A.
# Configure Loopback0 on Switch A as an 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 Switch E.

[SwitchE] multicast load-splitting stable-preferred
Step 6 Add the host-side interfaces of Switch E to multicast groups in batches.
# Add VLANIF140 to multicast groups from 225.1.1.1 to 225.1.1.3.

[SwitchE] interface Vlanif140
[SwitchE-Vlanif140] igmp static-group 225.1.1.1 inc-step-mask 32 number 3
[SwitchE-Vlanif140] quit
Step 7 Verify the configuration of stable-preferred multicast load splitting.
# The multicast source (10.110.1.1/24) sends multicast data to multicast groups 225.1.1.1 to
225.1.1.3. HostA can receive the multicast data from the multicast source. On Switch E, check
brief information about the PIM routing table.
<SwitchE> display pim routing-table brief
Total 3 (*, G) entries; 3 (S, G) entries
Entries Upstream interface NDwnstrms

(*, 225.1.1.1) Vlanif130 1
(10.110.1.1, 225.1.1.1) Vlanif130 1
(*, 225.1.1.2) Vlanif120 1
(10.110.1.1, 225.1.1.2) Vlanif120 1
(*, 225.1.1.3) Vlanif110 1
(10.110.1.1, 225.1.1.3) Vlanif110 1
(*, G) and (S, G) entries are evenly distributed to the three equal-cost routes, with the upstream
interfaces being VLANIF130, VLANIF120, and VLANIF110.
NOTE
The load splitting algorithm processes (*, G) and (S, G) entries separately with the same processing rule.
Step 8 Set different multicast load splitting weights for upstream interfaces of Switch E to ensure that
multicast traffic is distributed unevenly.
# Set the multicast load splitting weight on VLANIF110 to 2.

[SwitchE-Vlanif110] multicast load-splitting weight 2
# Set the multicast load splitting weight on VLANIF130 to 0.

[SwitchE-Vlanif130] multicast load-splitting weight 0
Step 9 Add the host-side interfaces of SwitchE to multicast groups in batches.
# Add VLANIF140 to multicast groups from 225.1.1.4 to 225.1.1.9.


[SwitchE-Vlanif140] igmp static-group 225.1.1.4 inc-step-mask 32 number 6
Step 10 Verify the configuration of uneven multicast load splitting.

# The multicast source (10.110.1.1/24) sends multicast data to multicast groups 225.1.1.1 to
225.1.1.9. HostA can receive the multicast data from the multicast source. On Switch E, check
brief information about the PIM routing table.
<SwitchE> display pim routing-table brief
Entries Upstream interface NDwnstrms

(*, 225.1.1.1) Vlanif130 1
(10.110.1.1, 225.1.1.1) Vlanif130 1
(*, 225.1.1.2) Vlanif120 1
(10.110.1.1, 225.1.1.2) Vlanif120 1
(*, 225.1.1.3) Vlanif110 1
(10.110.1.1, 225.1.1.3) Vlanif110 1
(*, 225.1.1.4) Vlanif110 1
(10.110.1.1, 225.1.1.4) Vlanif110 1
(*, 225.1.1.5) Vlanif110 1
(10.110.1.1, 225.1.1.5) Vlanif110 1
(*, 225.1.1.6) Vlanif110 1
(10.110.1.1, 225.1.1.6) Vlanif110 1
(*, 225.1.1.7) Vlanif120 1
(10.110.1.1, 225.1.1.7) Vlanif110 1
(*, 225.1.1.8) Vlanif110 1
(10.110.1.1, 225.1.1.8) Vlanif120 1
(*, 225.1.1.9) Vlanif110 1
(10.110.1.1, 225.1.1.9) Vlanif110 1
The upstream interfaces of existing (*, G) and (S, G) entries remain unchanged. The multicast
load splitting weight of VLANIF110 is greater than that of VLANIF120; therefore, the newly
generated entries with the upstream interface being VLANIF110 are more than those with the
upstream interface being VLANIF120. The multicast load splitting weight of VLANIF130 is 0,
indicating that VLANIF130 does not load balance new entries.
----End
Configuration Files
l Configuration file of Switch A.
#
sysname SwitchA
#
#
isis 1
network-entity 10.0000.0000.0001.00
#
interface Vlanif10
ip address 10.110.1.2 255.255.255.0
isis enable 1
pim sm
interface Vlanif20
ip address 192.168.1.1 255.255.255.0
isis enable 1
pim sm
interface Vlanif30
ip address 192.168.2.1 255.255.255.0
isis enable 1

pim sm
interface Vlanif40
ip address 192.168.3.1 255.255.255.0
isis enable 1
pim sm
port link-type hybrid
#
#
#
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
pim sm
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
return
l Configuration file of Switch B.
#
sysname SwitchB
#
#
isis 1
network-entity 10.0000.0000.0002.00
#
interface Vlanif50
ip address 192.168.1.2 255.255.255.0
isis enable 1
pim sm
interface Vlanif60
ip address 192.168.4.1 255.255.255.0
isis enable 1
pim sm
#
#
return
l Configuration file of Switch C.
#
sysname SwitchC
#
#
isis 1

network-entity 10.0000.0000.0003.00
#
interface Vlanif70
ip address 192.168.2.2 255.255.255.0
isis enable 1
pim sm
interface Vlanif80
ip address 192.168.5.1 255.255.255.0
isis enable 1
pim sm
#
#
return
l Configuration file of Switch D.
#
sysname SwitchD
#
#
isis 1
network-entity 10.0000.0000.0004.00
#
interface Vlanif90
ip address 192.168.3.2 255.255.255.0
isis enable 1
pim sm
interface Vlanif100
ip address 192.168.6.1 255.255.255.0
isis enable 1
pim sm
#
#
return
l Configuration file of Switch E.
#
sysname SwitchE
#
multicast load-splitting stable-preferred
#
isis 1
network-entity 10.0000.0000.0005.00
#
interface Vlanif110
ip address 192.168.4.2 255.255.255.0
isis enable 1
pim sm
multicast load-splitting weight 2
interface Vlanif120
ip address 192.168.5.2 255.255.255.0
isis enable 1

pim sm
interface Vlanif130
ip address 192.168.6.2 255.255.255.0
isis enable 1
pim sm
multicast load-splitting weight 0
interface Vlanif140
ip address 10.110.2.2 255.255.255.0
isis enable 1
pim sm
igmp static-group 225.1.1.1 inc-step-mask 0.0.0.1 number 3
igmp static-group 225.1.1.4 inc-step-mask 0.0.0.1 number 6
#
#
#
#
return

Configuration Guide - Multicast 10 MLD Configuration
10 MLD Configuration
About This Chapter
On an IPv6 network, by configuring MLD on an interface of a multicast device connected with

the user network segment, you can manage group members on the local network.
10.1 MLD Overview
MLD is short for Multicast Listener Discovery. It has two versions: MLDv1 and MLDv2.
MLDv1 supports the ASM model and MLDv2 can directly support the SSM model.
10.2 MLD Features Supported by the S9300
The MLD features supported by the system include: basic MLD functions, static MLD groups,
configuring the range of groups that an interface can join, controlling the Router-Alert option
in an MLD packet, configuring parameters of an MLD Query message, SSM mapping, and
limiting the number of MLD group memberships.
10.3 Configuring Basic MLD Functions
By configuring basic MLD functions on an interface of a multicast device connected with the
user network segment, you can enable a user host to access the multicast network and receive
multicast data packets.
10.4 Configuring Options of an MLD Packet
You can enable a multicast device to filter MLD Report messages and receive only the MLD
messages with Router-Alert options by configuring options of MLD messages.
10.5 Configuring MLD Query Control
An MLD querier periodically sends MLD Query messages on a shared network segment to
refresh information about IGMP group members. MLD parameters configured on all the
interfaces of the multicast devices on the same network segment with the user host should be
consistent; otherwise, a fault occurs on the network.
In the network segment where multicast services are provided in the SSM mode, the interface
of the multicast device runs MLDv2 while certain hosts can run only MLDv1 due to various
limitations. To ensure that the multicast device running a later IGMP version is compatible with
the hosts running an earlier IGMP version and provides SSM services for these hosts, you need
to configure static SSM mapping on the multicast device.
10.7 Configuration MLD Limit Function
If you want to restrict the servable IPTV ICPs and the number of access users on an IP core
network, the MLD limit function is required. Configuring the MLD limit function involves

setting the maximum number of global MLD group memberships, maximum number of global
MLD group memberships in a single instance, and maximum number of MLD group
memberships on an interface.
10.8 Maintaining MLD
Maintaining MLD involves resetting MLD group information, and monitoring MLD running
status.
Examples for configuring basic MLD functions and the MLD limit function in the multicast
network are provided.

10.1 MLD Overview

MLD is short for Multicast Listener Discovery. It has two versions: MLDv1 and MLDv2.
MLDv1 supports the ASM model and MLDv2 can directly support the SSM model.
The Multicast Listener Discovery (MLD) is a sub-protocol of the Internet Control Message
Protocol version 6 (ICMPv6). MLD is used to set up and maintain the membership of groups
between hosts and their directly connected multicast switchs. The functions and principles of
MLD are the same as those of the Internet Group Management Protocol (IGMP).MLD has the
following versions:
l MLDv1
MLDv1 is defined in RFC 2710, and is derived from IGMPv2. MLDv1 supports the Any-
Source Multicast (ASM) model. With the help of SSM mapping, MLDv1 can support the
Source-Specific Multicast (SSM) model.
l MLDv2
MLDv2 is defined in RFC 3810, and is derived from IGMPv3. MLDv2 supports the ASM
and SSM models.
10.2 MLD Features Supported by the S9300

The MLD features supported by the system include: basic MLD functions, static MLD groups,
configuring the range of groups that an interface can join, controlling the Router-Alert option
in an MLD packet, configuring parameters of an MLD Query message, SSM mapping, and
limiting the number of MLD group memberships.
Basic MLD Function

You can enable MLD and configure the MLD version.
Static MLD Group

You can configure an interface to statically join a multicast group. After the interface statically
joins a group, the system considers that the network segment where the interface resides has a
member of the group.
Configuring the Range of Groups that an Interface Can Join

You can set the range of groups that an interface can join as required.
Controlling the Router-Alert Option in an MLD Packet

You can determine whether to set the Router-Alert option in the MLD packets to be sent, and
whether to require that the received MLD packets contain the Router-Alert option.
Configuring Parameters of an MLD Query Message

You can set the interval for sending general query messages, MLD robustness variable, the
maximum response time of MLD Query messages, Keepalive period of other MLD queriers,
the interval for sending MLD group-specific query messages, and MLD fast leave.

SSM Mapping
For MLDv1 hosts, you can configure SSM mapping to build a multicast network of the SSM
model.
Limiting the Number of MLD Group Memberships

l Limiting the total number of MLD group memberships on a switch: The total number of
MLD group memberships created by a switch cannot exceed the limit value. When the total
number of MLD group memberships created by a switch exceeds the limit value, no MLD
entry can be created.
l Limiting the total number of MLD group memberships in a single instance: The total
number of MLD group memberships related to an instance cannot exceed the limit value.
When the total number of MLD group memberships related to an instance reaches the limit
value, no MLD entry can be created.
l Limiting the total number of MLD group memberships on an interface: The total number
of MLD group memberships created on an interface cannot exceed the limit value. When
the total number of MLD group memberships created on an interface reaches the limit
value, no MLD entry can be created.
10.3 Configuring Basic MLD Functions

By configuring basic MLD functions on an interface of a multicast device connected with the
user network segment, you can enable a user host to access the multicast network and receive
multicast data packets.

Before configuring basic MLD functions, familiarize yourself with the applicable environment,
MLD is applicable to the switch and the hosts directly connected to the switch. The switch and
hosts need to run MLD. This section only describes how to configure MLD on a switch.
You must enable IPv6 multicast routing before configuring MLD. IPv6 multicast routing is the
prerequisite for configuring IPv6 multicast functions. If the IPv6 multicast routing is disabled,
all IPv6 multicast configurations are deleted.
Enable MLD on the interface connected to hosts. For different MLD versions, MLD packets are
different; therefore, you need to configure matching MLD versions for switchs and hosts. Other
MLD configurations can be done only after the preceding operations are complete.
To enable hosts in the network segment to which the interface is connected to join the specified
groups and receive packets to the groups, you can set a group policy on the related interface to
limit the range of groups that the interface serves.
Before configuring basic MLD functions, configure a unicast routing protocol to interconnect
the entire multicast domain.

Data Preparation
To configure basic MLD functions, you need the following data.
No. Data
1 MLD version
2 Group address and source address
3 ACL6 rules for filtering multicast groups

Before configuring basic MLD functions, enable IPv6 multicast routing.
Context
Do as follows on the switch connected to hosts:
Procedure
Step 1 Run:
system-view

Step 2 Run:
multicast ipv6 routing-enable
IPv6 multicast routing is enabled in the public network instance.
----End
10.3.3 Enabling MLD

After MLD is enabled on an interface of a multicast device connected with the user network
segment, user hosts can dynamically join multicast groups.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:

interface-type interface-number specifies the interface connected to hosts.

Step 3 Run:
mld enable
MLD is enabled on the interface.

By default, MLD is not enabled on the interface.
----End
10.3.4 (Optional) Configuring the MLD Version

You need to configure the version of MLD enabled on the interface of a multicast device
connected with the user network segment. Note that the versions of MLD enabled on the
multicast devices on the same network segment should be the same; otherwise, a network
abnormality occurs.
Context
CAUTION
Ensure that all MLD switch interfaces in the same network segment are configured with the
same MLD version. Otherwise, faults may occur.
This configuration is optional. By default, MLDv1 is adopted.

Procedure
Step 1 Run:
system-view

Step 2 Run:

Trunk interface.
Step 3 Run:
mld version { 1 | 2 }
The MLD version of the interface level is configured.

By default, MLDv1 is adopted.
----End
10.3.5 (Optional) Configuring an Interface to Statically Join a Group

After a static MLD group is configured on the interface that connects a multicast device to the
user network segment, the multicast device considers that the interface has multicast group

members and keeps on forwarding matched multicast packets to the network segment where this
interface resides.
Context
NOTE
This configuration is optional. By default, the interface does not statically join any group.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
mld static-group ipv6-group-address [ inc-step-mask ipv6-group-mask-length number
group-number ] [ source ipv6-source-address ]
The interface is configured to statically join a single multicast group or multiple multicast groups
in batches. After the interface statically joins the multicast groups, the switch considers that the
members of the multicast groups exist on the network segment where the interface resides.
----End
10.3.6 (Optional) Configuring the Range of Groups an Interface Can

Join
You can configure the range of groups on the interface of a multicast device connected with the
user network segment so that user hosts can join only a specified range of multicast groups.
Context
NOTE
This configuration is optional. By default, the interface can join any group.
Procedure
Step 1 Run:
system-view
Step 2 Run:


Step 3 Run:
mld group-policy { acl6-number | acl6-name acl6-name } [ 1 | 2 ]
The range of groups that the interface can join is configured.
----End

After configuring basic MLD functions, check the configuration and running information about
MLD on the interface and memberships of MLD multicast groups to ensure that MLD runs
normally.
Procedure
l Run the display mld interface [ interface-type interface-number ] [ verbose ] command
to check the MLD configuration and running information on an interface.
l Run the display mld group [ ipv6-group-address | interface interface-type interface-
number ] * [ static ] [ verbose ] command to check information on members of an MLD
multicast group.
----End
10.4 Configuring Options of an MLD Packet

You can enable a multicast device to filter MLD Report messages and receive only the MLD
messages with Router-Alert options by configuring options of MLD messages.

Before configuring options of an MLD message, familiarize yourself with the applicable
MLD has the group-specific and source/group-specific query messages. The groups are varied.
Switchs cannot join all groups. The Router-Alert option is used to send the MLD packets of
which the multicast group is not specified by the upper-layer protocol of the IP layer to the upper-
layer protocol for processing.
Before configuring options of an MLD packet, complete the following tasks:
l Configuring a unicast routing protocol to interconnect the entire multicast domain
l Configuring Basic MLD Functions
Data Preparation
To configure options of an MLD packet, you need the following data.

No. Data
1 Whether the Router-Alert option is set in the packet
10.4.2 Configuring the Router-Alert Option of an MLD Packet

To make the multicast device connected with the user network segment or other MLD interfaces
on the same network segment receive only the MLD messages with Router-Alert options, you
can configure a Router-Alert option for MLD messages on the multicast device connected with
the user network segment.
Context
This configuration is optional. By default, MLD packets sent by switchs carry the Router-Alert
option, but the switchs do not check the Router-Alert option. That is, the switchs process all the
received MLD packets, including those without the Router-Alert option.
NOTE

l Global configuration: It is valid on all interfaces.
Procedure
1. Run:
system-view

2. Run:
mld
The MLD view is displayed.

3. Run:
require-router-alert
The Router-Alert option is required in the received MLD packet.
If the received the MLD packet does not carry the Router-Alert option, the packet is
discarded.
4. Run:
send-router-alert
The Router-Alert option is set in the header of the MLD packet to be sent.
1. Run:
system-view


2. Run:

3. Run:
mld require-router-alert
The Router-Alert option is required in the received MLD packet.

If the received the MLD packet does not carry the Router-Alert option, the packet is
discarded.
4. Run:
mld send-router-alert
The Router-Alert option is set in the header of the MLD packet to be sent.
----End

After options of MLD messages are configured, you can check MLD configurations and running
information on the interface to ensure normal running of MLD.
Procedure
l Run the display mld interface [ interface-type interface-number | up | down ]
[ verbose ] command to check the MLD configuration and running information on an
interface.
----End
10.5 Configuring MLD Query Control

An MLD querier periodically sends MLD Query messages on a shared network segment to
refresh information about IGMP group members. MLD parameters configured on all the
interfaces of the multicast devices on the same network segment with the user host should be
consistent; otherwise, a fault occurs on the network.

Before configuring MLD query control, familiarize yourself with the applicable environment,
CAUTION
A great many of MLD interfaces exist in the network and these MLD interfaces are mutually
restricted. Ensure that all MLD parameters of all MLD switch interfaces on the same network
segment are identical. Otherwise, the network may be faulty.

The MLD querier periodically sends MLD Query messages on the share network connected to
receivers. When receiving a Report message from a member, the switchs on the shared network
refresh information about the member relationship.
If non-queriers do not receive any query message within the Keepalive period of the MLD
querier, the querier is considered faulty, and a new round of the querier election is triggered
automatically.
In the application of ADSL dial-up access, one host corresponds to a port. A querier, therefore,
corresponds to only one receiver host. When a receiver host switches among multiple groups
such as TV channels, you can enable the fast leave mechanism on the querier.
Before configuring MLD query control, complete the following tasks:
Data Preparation
To configure MLD query control, you need the following data.
No. Data
1 The interval for sending MLD general Query messages
2 Robustness variable
3 The maximum response time of the MLD Query message
4 Keepalive period of the other MLD queriers
5 The interval for sending MLD group-specific Query messages and group/source-
specific Query messages
6 ACL6 that limits the application range of prompt leave
10.5.2 (Optional) Configuring MLD Query and Response

Configuring an MLD querier involves setting the interval for sending general query messages,
MLD robustness variable, maximum response time of the MLD Query message, Keepalive
period of other MLD queriers, and interval for sending last listener query messages, and enabling
the MLD fast leave function.
Context
CAUTION
In the actual configuration, ensure that the interval for sending general Query messages is greater
than the maximum response time and is smaller than the Keepalive time of the other MLD
queriers.

NOTE

l Global configuration: It is valid on all interfaces.
Procedure
1. Run:
system-view

2. Run:
mld

3. Run:
The interval for sending Query messages is set.
By default, the interval for sending Query messages is 125 seconds.

4. Run:
The MLD robustness variable is set.
By default, the MLD robustness variable is 2.
– When a switch starts, the switch sends general query messages for the number of
robust-value times. The sending interval is 1/4 of the interval for sending MLD
general query messages.
– When a switch receives a Leave message, the switch sends MLD last listener query
messages for the number of robust-value times.
The greater the robustness variable is, the longer the timeout period of the group is.
5. Run:
max-response-time interval
The maximum response time of the MLD Query message is set.
By default, the maximum MLD response time is 10 seconds.

6. Run:
timer other-querier-present interval
The interval for the Keepalive period of the other MLD queriers is set.
By default, the formula used to calculate the Keepalive period of the other queriers
is: the Keepalive period of the other MLD queriers = robustness variable x the interval
for sending MLD general query messages + 1/2 x the MLD maximum response time.
When default values of robustness variable, the interval for sending MLD general

query messages, and maximum response time are used, the Keepalive period of the
other MLD queriers is 255 seconds.
7. Run:
lastlistener-queryinterval interval
The interval for sending last listener query messages is set.
The shorter the interval, the more sensitive the querier. By default, the interval is 1
second.
1. Run:
system-view

2. Run:

3. Run:
mld timer query interval
The interval for sending MLD general query messages is set.

4. Run:
mld max-response-time interval
The maximum response time of the MLD Query message is set.

5. Run:
mld timer other-querier-present interval
The Keepalive period of the other MLD queriers is set.

6. Run:
mld robust-count robust-value
The MLD robustness variable is set.

7. Run:
mld lastlistener-queryinterval interval
The interval for sending MLD last listener query messages is set.
8. Run:
mld prompt-leave [ group-policy { basic-acl6-number | acl6-name acl6-
name } ]
MLD fast leave is configured.
When an interface receives a Leave message for a certain group, the interface
immediately deletes the downstream interface of the entry to which the group
corresponds, without sending the last listener query message.
By default, when a switch receives a Leave message for a group, the switch sends last
listener query messages.
This command is only valid for MLDv1.
----End


After MLD query control is configured, you can check MLD configurations and running
information on the interface to ensure normal running of MLD.
Procedure
interface.
----End

In the network segment where multicast services are provided in the SSM mode, the interface
of the multicast device runs MLDv2 while certain hosts can run only MLDv1 due to various
limitations. To ensure that the multicast device running a later IGMP version is compatible with
the hosts running an earlier IGMP version and provides SSM services for these hosts, you need
to configure static SSM mapping on the multicast device.

Before configuring SSM mapping, familiarize yourself with the applicable environment, pre-
configuration tasks, and required data. This can help you complete the configuration task quickly
and accurately.
In the SSM host network segment, the switch can know the specific source when a host joins a
group. The SSM solutions are as follows:
l Hosts and switchs run MLDv2. When a host joins a group, the host specifies the source
from which the host wants to receive data.
l If some hosts in the network segment can run only MLDv1, the hosts cannot specify the
sources from which they want to receive data when joining related groups. In this case, you
need to configure SSM mapping and static mapping rules on the switch. As a result, the (*,
G) information carried in the Report message is mapped to the (G, INCLUDE, (S1, S2, ...))
information.
Before configuring SSM mapping, complete the following tasks:

Data Preparation

No. Data
1 Interface that needs to be enabled with SSM mapping
2 Group address/mask and source address/mask
10.6.2 Enabling SSM Mapping

Prior to configuring SSM mapping, enable SSM mapping on the interface that connects the
multicast device to the user network segment; otherwise, the SSM entries do not take effect.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mld enable
MLD is enabled.
Step 4 Run:
mld version 2
The MLD version is set to 2.

By default, the MLD version is 1.
To ensure that the hosts that run any MLD version on the network segment can obtain the SSM
services, it is recommended to configure MLDv2 on the switch interface.
Step 5 Run:
mld ssm-mapping enable
The SSM mapping is enabled.
----End
10.6.3 Configuring the Static SSM Mapping Policy

You can configure SSM mapping on the interface that connects the multicast device to the user
network segment to enable the user hosts that support only MLDv1 but not MLDv2 to join a
specific source/group. In this manner, the multicast device running a later MLD version is
compatible with the hosts running an earlier MLD version and can provide the SSM service for
these hosts.

Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
mld
Step 3 Run:
ssm-mapping ipv6-group-address ipv6-group-mask-length ipv6-source-address
The mapping from the source to the group is set.
You can run the command repeatedly to configure the mapping from a group to multiple sources.
l ipv6-group-address ipv6-group-mask-length: specifies the group address and mask. The

group address must be in the SSM group address range.
l ipv6-source-address: specifies the address of the source that sets up the mapping relationship
with the group.
----End

After SSM mapping is configured, you can check MLD configurations and running information,
SSM mapping information of a source-specific group, information about the interface enabled
with SSM mapping, and SSM mapping rules of a specified group to ensure that SSM mapping
runs normally.
Procedure
interface.
number ] * ssm-mapping [ verbose ] to check information about a source/group-specific
address.
l Run the display mld ssm-mapping interface [ interface-type interface-number [ group
ipv6-group-address ] ] command to check information about an interface enabled with SSM
mapping.
l Run the display mld ssm-mapping group [ ipv6-group-address ] command to check SSM
mapping rules of a specified group address.
----End

10.7 Configuration MLD Limit Function

If you want to restrict the servable IPTV ICPs and the number of access users on an IP core
network, the MLD limit function is required. Configuring the MLD limit function involves
setting the maximum number of global MLD group memberships, maximum number of global
MLD group memberships in a single instance, and maximum number of MLD group
memberships on an interface.

Before configuring the MLD limit function, familiarize yourself with the applicable
To limit IPTV ICPs and the number of users accessing IP core networks, you can configure the
MLD limit function.
The MLD limit function is configured on the last-hop switch connected to users. You can perform
the following configurations as required:
l Configure the maximum number of global MLD group memberships on a switch.

l Configure the maximum number of MLD entries in a single instance.
l Configure the maximum number of MLD group memberships on an interface.
NOTE
If the MLD limit function is required to be configured globally, for a single instance, and for an interface
on the same switch, it is recommended that the limits on the number of global MLD group memberships,
the number of MLD group memberships in the single instance, and the number of MLD group memberships
on the interface should be in descending order.
Before configuring the MLD limit function, complete the following task:

Data Preparation
To configure the MLD limit function, you need the following data.
No. Data
1 Maximum number of global MLD group memberships
2 Maximum number of MLD group memberships in a single instance
3 Maximum number of MLD group memberships on an interface

10.7.2 Configuring the Maximum Number of Global MLD Group

Memberships
Configure the maximum number of MLD entries that can be created on the multicast device
connected with the user network segment. When the number of MLD entries reaches the limit,
the system does not create any new MLD entry. If the host wants to join a new multicast group,
you need to delete certain useless entries, modify the limit, or configure the host to statically
join a multicast group or source/group.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
mld global limit number
The maximum number of global MLD entries of all instances is set.
----End
10.7.3 Configuring the Maximum Number of Global MLD Entries

in a Single Instance
Configure the maximum number of MLD entries that can be created in a single instance on the
multicast device connected with the user network segment. When the number of MLD entries
reaches the limit, the system does not create any new MLD entry. If the host wants to join a new
multicast group, you need to delete certain useless entries, modify the limit, or configure the
host to statically join a multicast group or source/group.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
mld

Step 3 Run:
limit number

The maximum number of global MLD entries in a single instance is set.
----End
10.7.4 Configuring the Maximum Number of MLD Group

Memberships on an Interface
Configure the maximum number of MLD entries that can be created on the interface of the
multicast device connected with the user network segment. When the number of MLD entries
reaches the limit, the system does not create any new MLD entry. If the host wants to join a new
multicast group, you need to delete certain useless entries, modify the limit, or configure the
host to statically join a multicast group or source/group.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
The MLD interface view is displayed.
Step 3 Run:
mld limit number [ except { acl6-number | acl6-name acl6-name } ]
The maximum number of MLD group memberships is set on the interface.
NOTE
If except is not specified in the command, the router is limited by the maximum number of MLD entries
when creating the entries for all the groups or source/groups.
Before specifying except, you need to configure the corresponding ACl. Then, the interface filters the
received MLD Join messages according to the ACL. The number of entries that are filtered according to
the ACL is not limited by the maximum number of MLD entries.
----End

After configuring MLD limit, check the configuration and running information about MLD on
the interface and memberships of MLD multicast groups to ensure that MLD runs normally.
Procedure
[ verbose ] command to check the configuration and running of MLD on an interface.
l Run the following commands to check information about the members of an MLD multicast
group.

– display mld group [ ipv6-group-address | interface interface-type interface-number ]

* [ verbose ]
– display mld group [ ipv6-group-address | interface interface-type interface-number ]

* ssm-mapping [ verbose ]
# Run the display mld interface command to view the configuration and running status
of MLD on the switch interface. The display information is as follows:
<SwitchA> display mld interface vlanif 10
Vlanif10(FE80::200:5EFF:FE66:5100):
MLD is enabled
Current MLD version is 1
MLD state: up
MLD group policy: none
MLD limit: 30
Value of query interval for MLD (negotiated): 125 s
Value of query interval for MLD (configured): 125 s
Value of other querier timeout for MLD: 0 s
Value of maximum query response time for MLD: 10 s
Querier for MLD: FE80::200:5EFF:FE66:5100 (this switch)
From the display, you can see the maximum number of MLD group members on VLANIF
10 of Switch A.
----End
10.8 Maintaining MLD

Maintaining MLD involves resetting MLD group information, and monitoring MLD running
status.
10.8.1 Clearing Information about MLD Groups

After you confirm to clear the statistics on MLD groups, use the reset commands in the user
view. The receiver cannot receive multicast information normally if the MLD group that the
interface dynamically joins is deleted. Therefore, confirm the action before you use the reset
commands.
Context
CAUTION
The MLD groups that an interface dynamically joins are deleted after you run the reset mld
group or the reset mld group ssm-mapping command. Receivers may not receive multicast
information normally. So, confirm the action before you use the command.
Procedure
l Run the reset mld explicit-tracking { all | interface interface-type interface-number
[ host ipv6-host-address [ group ipv6-group-address [ source ipv6-source-address ] ] ] }
command in the user view to clear the hosts that join a multicast group through MLD on
an interface.

l Run the following commands in the user view to clear the MLD groups that the interface
dynamically joins (not including the MLDv1 group in the SSM range).
– reset mld group all
– reset mld group interface interface-type interface-number { all | ipv6-group-
address [ ipv6-group-mask-length ] [ ipv6-source-address [ ipv6-source-mask-
length ] ] }
l Run the following commands in the user view to clear MLDv1 groups in the SSM range.
– reset mld group ssm-mapping all
– reset mld group ssm-mapping interface interface-type interface-number { all | ipv6-
group-address [ ipv6-group-mask-length ] }
l Run the reset mld control-message counters [ interface interface-type interface-
number ] [ message-type { query | report } ] command in the user view to delete statistics
of MLD messages.
----End
10.8.2 Monitoring the Running Status of MLD

During MLD routine maintenance, you can run the display commands in any view to know the
running of MLD.
Context
status of MLD.
Procedure
l Run the display mld explicit-tracking [ interface interface-type interface-number [ host-
address ipv6-host-address | group ipv6-group-address source ipv6-source-address ] ]
command in any view to check information about the MLD hosts on an interface.
number ] * [ static ] [ verbose ] command in any view to check information about groups
on each interface.
number ] * ssm-mapping [ verbose ] command in any view to check information about a
group configured with SSM mapping.
l Run the display mld interface [ interface-type interface-number ] [ verbose ] command
in any view to check the MLD configuration and running information on an interface.
l Run the display mld routing-table [ ipv6-source-address [ ipv6-source-mask-length ] |
ipv6-group-address [ ipv6-group-mask-length ] ] * [ static ] [ outgoing-interface-
number [ number ] ] command in any view to check the MLD routing table.
l Run the display mld ssm-mapping interface [ interface-type interface-number [ group
ipv6-group-address ] ] command in any view to check information about an interface
enabled with SSM mapping.
l Run the display mld ssm-mapping group [ ipv6-group-address ] command in any view
to check SSM mapping rules of a specified group address.

l Run the display mld control-message counters [ interface interface-type interface-

number ] [ message-type { query | report } ] command in any view to check the statistics
of MLD messages received by interfaces.
----End
10.8.3 Debugging MLD

When an MLD running fault occurs, run the debugging commands in the user view and locate
the fault based on the debugging information. Debugging affects the performance of the system.
So, after debugging, disable it immediately.
Context
CAUTION
Debugging affects the performance of the system. After debugging, you need to run the undo
debugging all command to disable the debugging immediately.
When an MLD fault occurs, run the following debugging commands in the user view to locate
the fault.
For the explanation of debugging commands, refer to the Quidway S9300 Terabit Routing
Procedure
l Run the debugging mld { all | done [ basic-acl6-number ] | event [ advanced-acl6-
number ] | query [ basic-acl6-number ] [ receive | send ] | report [ advanced-acl6-
number ] | timer } command in the user view to enable the debugging of MLD.
l Run the debugging mld ssm-mapping [ advanced-acl6-number ] command in the user
view to enable the debugging of SSM mapping.
----End

Examples for configuring basic MLD functions and the MLD limit function in the multicast
network are provided.
10.9.1 Example for Configuring Basic MLD Functions
On the IPv6 network shown in Figure 10-1, unicast routes are normal. It is required to implement
multicast on the network to enable hosts to receive the Video on Demand (VoD) information.

Figure 10-1 Networking diagram for configuring basic MLD functions

Ethernet
HostA
SwitchA Receiver
GE2/0/0 N1
GE1/0/0
3000::12/64 HostB
SwitchB
Leaf network
GE2/0/0
GE1/0/0
PIM network 3001::10/64 HostC
SwitchC Receiver
N2
GE2/0/0 GE1/0/0 HostD
3001::12/64
Ethernet

SwitchA GE1/0/0 VLANIF100 3000::12/64
GE2/0/0 VLANIF101 2002::1/64
SwitchB GE1/0/0 VLANIF200 3001::10/64
GE2/0/0 VLANIF201 2002::1/64
SwitchC GE1/0/0 VLANIF300 3001::12/64
GE2/0/0 VLANIF301 2002::1/64
1. Enable IPv6 Multicast on the S9300s.
2. Enable IPv6 PIM-SM on all the interfaces on S9300.
3. Enable MLD on the interface at the host side.
Data Preparation
l MLD version running between the S9300s and the user hosts
Procedure
Step 1 Create VLANs and VLAN interfaces on the S9300s and assign IP addresses to the VLAN
interfaces. The configuration procedure is not provided here.
Step 2 Enable multicast on the S9300s and enable MLD and IPv6 PIM-DM on the interfaces connected
to user hosts.
# Enable multicast on SwitchA, enable MLD and IPv6 PIM-DM on VLANIF 100, and set the
MLD version to 2.

[SwitchA] multicast ipv6 routing-enable
[SwitchA-Vlanif100] pim ipv6 sm
[SwitchA-Vlanif100] mld enable
[SwitchA-Vlanif100] mld version 2
The configurations of SwitchB and SwitchC are similar to the configuration of SwitchA, and
# Run the display mld interface command, and you can check the configuration and running
status of MLD on each interface. MLD information on VLANIF 200 of SwitchB is as follows:
<SwitchB> display mld interface vlanif 200
Vlanif200(FE80::200:5EFF:FE66:5100):
MLD is enabled
MLD state: up
MLD limit: -
Value of query interval for MLD (negotiated): 125 s
Value of last listener query time: 2 s
Value of last listener query interval: 1 s
Value of startup query interval: 31 s
Value of startup query count: 2
General query timer expiry (hours:minutes:seconds): 00:00:28
Querier for MLD: FE80::200:5EFF:FE66:5100 (this router)
MLD activity: 0 joins, 0 dones
Robustness (negotiated): 2
Robustness (configured): 2
Require-router-alert: disabled
Send-router-alert: enabled
Prompt-leave: disabled
SSM-Mapping: disabled
Startup-query-timer-expiry: on
Other-querier-present-timer-expiry: off
From the display, you can see that SwitchB is a querier. This is because the IPv6 address of
VLANIF 200 on S9300B is the smallest on the network segment.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 101
#
ipv6
#
#
interface Vlanif101
ipv6 enable
ipv6 address 2002::1/64
pim ipv6 sm
#
interface Vlanif100

ipv6 enable
pim ipv6 sm
mld enable
mld version 2
#
#
#
return
#
sysname SwitchB
#
vlan batch 200 201
#
ipv6
#
#
interface Vlanif201
ipv6 enable
pim ipv6 sm
#
interface Vlanif200
ipv6 enable
pim ipv6 sm
mld enable
mld version 2
#
#
#
return
#
sysname SwitchC
#
vlan batch 300 301
#
ipv6
#
#
interface Vlanif301
ipv6 enable
pim ipv6 dm
#
interface Vlanif300
ipv6 enable
pim ipv6 dm
mld enable
mld version 2
#

#
#
return
10.9.2 Example for Configuring MLD Limit
When a large number of users watch multiple programs simultaneously, great bandwidth of
devices is consumed, which degrades the performance of the devices and lowers the stability of
receiving multicast data.
The existing multicast technologies control multicast networks by limiting the number of
multicast forwarding entries or the number of outgoing interfaces of an entry, which cannot meet
the requirements of operators for real-time video services on IPTV networks and flexible
management of network resources.
Configuring MLD limit can enable operators to properly plan network resources and flexibly
control the number of multicast groups that hosts can join. In the network shown in Figure
10-2, multicast services are deployed. The global MLD limit, instance-based MLD limit, and
interface-based MLD limit are configured on Switch A, Switch B, and Switch C connected to
hosts to limit the number of multicast groups that the hosts can join. When the number of
multicast groups that hosts can join reaches the limit, the devices are not allowed to create new
MLD entries. This ensures that the users that join related multicast groups more clearly and
stably watch related programs.
Figure 10-2 Networking diagram of configuring MLD Limit

Ethernet
HostA
SwitchA Receiver
GE2/0/0 N1
GE1/0/0
HostB
SwitchB
Leaf network
GE2/0/0
GE1/0/0
HostC
PIM network
SwitchC Receiver
N2
GE2/0/0 GE1/0/0 HostD
Ethernet

SwitchA GE1/0/0 VLANIF100 3000::12/64
GE2/0/0 VLANIF101 2001::1/64
SwitchB GE1/0/0 VLANIF200 3001::10/64

GE2/0/0 VLANIF201 2002::1/64

SwitchC GE1/0/0 VLANIF300 3001::12/64
GE2/0/0 VLANIF301 2003::1/64
1. Enable IPv6 multicast.

2. Enable PIM-IPv6-SM on all switch interfaces.
3. Enable MLD on the interface at the host side.
4. Limit the number of MLD group memberships on Switch A, Switch B, and Switch C.
Data Preparation
l the version number of MLD of switches and user hosts.
l The maximum number of MLD group memberships.
Procedure
Step 1 Assign IP addresses to interfaces on the switches according to Figure 10-2. The configuration
Step 2 Enable multicast on switches and MLD and PIM-IPv6-SM on the interface at the host side.
# Enable multicast on Switch A, enable MLD and PIM-IPv6-SM on VLANIF 100.

[SwitchA-Vlanif100] mld enable
# The configurations of Switch B and Switch C are the same as the configuration of Switch A,
and are not mentioned here.
Step 3 Limit the number of MLD group memberships on the last-hop switch connected to users.
# Configure the maximum number of MLD group memberships to 50 on Switch A.

[SwitchA] mld global limit 50
# Configure the maximum number of MLD group memberships to 40 in the public network
instance.
[SwitchA] mld
[SwitchA-mld] limit 40
[SwitchA-mld] quit
# Configure the maximum number of MLD group relationships to 30 on VLANIF 100.


[SwitchA-Vlanif100] mld limit 30
# Configurations of Switch B and Switch C are similar to those of Switch A, and are not
mentioned here.
# Run the display mld interface command to view the configuration and running status of MLD
on the switch interface. MLD information on VLANIF 100 of Switch B is as follows:
[SwitchB] display mld interface vlanif 100
Vlanif100(FE80::200:5EFF:FE66:5100):
MLD is enabled
MLD state: up
MLD limit: 30
Value of query interval for MLD (negotiated): -
From the display, you can see that the maximum number of MLD group members that the
VLANIF 100 of Switch B can creat is 30.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 101
#
ipv6
#
mld global limit 50
#
#
interface Vlanif100
ipv6 enable
pim ipv6 sm
mld enable
mld limit 30
#
interface Vlanif101
ipv6 enable
pim ipv6 sm
#
#
pport hybrid pvid vlan 101
#
mld

limit 40
#
return
#
sysname SwitchB
#
vlan batch 200 201
#
ipv6
#
mld global limit 50
#
#
interface Vlanif200
ipv6 enable
pim ipv6 sm
mld enable
mld version 1
mld limit 30
#
interface Vlanif201
ipv6 enable
pim ipv6 sm
#
#
#
mld
limit 40
#
return
#
sysname SwitchC
#
vlan batch 300 101
#
ipv6
#
mld global limit 50
#
#
interface Vlanif300
ipv6 enable
pim ipv6 sm
mld enable
mld version 1
mld limit 30
#
interface Vlanif301
ipv6 enable
pim ipv6 sm
#

#
#
mld
limit 40
#
return

Configuration Guide - Multicast 11 MLD Snooping Configuration
11 MLD Snooping Configuration
About This Chapter
This chapter describes the implementation and configuration procedures of Multicast Listener
Discovery (MLD) snooping on the S9300.
11.1 Overview of MLD Snooping
When MLD snooping is enabled, the S9300 creates a Layer 2 forwarding table for multicast
data packets by listening to MLD messages. In this manner, the S9300 manages and controls
the forwarding of multicast data packets to ensure that these packets are sent only to the hosts
that need the multicast data.
11.2 MLD Snooping Features Supported by the S9300
This section describes the MLD snooping features supported by the S9300.
11.3 Enabling MLD Snooping
This section describes how to enable MLD snooping, add an interface to a multicast group
statically, and configure an interface as a static router interface.
11.4 Configuring a Multicast Group Policy for a VLAN
This section describes how to configure a multicast group policy for a VLAN.
11.5 Configuring Prompt Leave of Interfaces
This section describes how to configure prompt leave of interfaces in a VLAN.
11.6 Configuring the MLD Snooping Querier
This section describes how to configure the MLD snooping querier.
11.7 (Optional) Modifying Parameters of MLD Snooping
This section describes how to optimize the performance of MLD snooping by modifying MLD
snooping parameters, including the aging time of the router interface, interval for sending Last
Member Query messages, interval for sending the General Query messages, maximum response
time for MLD messages, MLD robustness variable, source IP address of the MLD message sent
to respond to changes of Layer 2 network topology, MLD version, duration for suppressing the
same Report messages, maximum number of MLD snooping entries, and whether the Router
Alert option is contained in MLD messages.
11.8 Maintaining MLD Snooping
This section describes how to maintain MLD snooping.

This section provides several configuration examples of MLD snooping.

11.1 Overview of MLD Snooping

When MLD snooping is enabled, the S9300 creates a Layer 2 forwarding table for multicast
data packets by listening to MLD messages. In this manner, the S9300 manages and controls
the forwarding of multicast data packets to ensure that these packets are sent only to the hosts
that need the multicast data.
If MLD snooping is disabled, IPv6 multicast packets are broadcast in the VLAN, which wastes
network bandwidth. MLD snooping has the following advantages:
l Reducing broadcast packets on the Layer 2 network to save network bandwidth

l Improving information security
l Implementing separate accounting of each host
11.2 MLD Snooping Features Supported by the S9300

This section describes the MLD snooping features supported by the S9300.
Basic Features of MLD Snooping

The S9300 supports the following basic features of MLD snooping:
l Supporting MLDv1 and MLDv2 packets
l Configuring VLAN-based multicast policies and multicast entries to control the access
from hosts in a VLAN to an IP multicast group
l Adding interfaces in a VLAN to a multicast group statically
l Configuring an interface in a VLAN as a static router interface to enable users to receive
multicast data steadily for a long time, because the static router interface never ages
l Responding to changes of the Layer 2 network and forwarding multicast data correctly
based on the new network topology
MLD Snooping Timers

On the S9300, you can set the following MLD snooping timers:
l Aging timer of the router interface in a VLAN.

By default, if the router interface receives an MLD Query message, the S9300 sets the
remaining aging time of the interface to 180 seconds. If the router interface receives a PIM
Hello message, the S9300 sets the remaining aging time of the interface to the value of the
holdtime field in the PIM Hello message.
l Maximum response time of MLD messages. This timer controls the deadline for a host to
report the membership.
l Robustness variable of MLD snooping in a VLAN. When sending the MLD Query
messages, the S9300 determines the retransmission count of an MLD message according
to the robustness variable.
l Interval for sending the MLD General Query messages. This timer helps the S9300 adapt
to the change of load on the network.

l Interval for sending the MLD Last Member Query messages. This timer helps the S9300
adapt to the change of load on the network.
l Duration for suppressing the Report messages. This timer saves network bandwidth and
reduces loads on the network.
Router Alert Option

The S9300 processes MLD messages differently based on whether the Router Alert option is
contained in MLD messages.
By default, the S9300 processes an MLD message regardless of whether the IP header of message
contains the Router Alert option. The S9300 sends the MLD messages that contain the Router
Alert option in the IP headers to the hosts in the VLAN.
You can determine whether MLD messages contain the Router Alert option.
Prompt Leave of Member Interfaces

When an interface of the S9300 receives an MLD Leave message of a multicast group, the
S9300 deletes the forwarding entry of the multicast group corresponding to the interface from
the forwarding table instead of sending Query messages. This process is called prompt leave.
When an interface is connected to only one host, you can enable the prompt leave function so
that the bandwidth can be released immediately after the host leaves the multicast group.
11.3 Enabling MLD Snooping

This section describes how to enable MLD snooping, add an interface to a multicast group
statically, and configure an interface as a static router interface.
By default, MLD snooping is disabled on the S9300. Therefore, you need to enable MLD
snooping on the S9300 globally.
After MLD snooping is enabled on the S9300 globally, MLD snooping remains disabled in a
VLAN by default. Therefore, you also need to enable MLD snooping in the VLAN.
If the hosts connected to an interface need to receive the multicast data of a certain group, you
can add the interface statically to the multicast group. The interface is called a static member
interface. The static member interface never ages.
On a network with stable topology, you can set the router interface on the S9300 as a static router
interface. The static router interface never ages, and can be deleted only through a certain
command.
Before enabling MLD snooping, complete the following tasks:
l Creating a VLAN

l Adding interfaces to the VLAN
Data Preparation
To enable MLD snooping, you need the following data.
No. Data
1 ID of the VLAN where MLD snooping needs

to be enabled
2 Number of the static member interface to be

configured, ID of the VLAN to which the
interface is to be added, and multicast IPv6
address
3 Number of the static router interface to be

configured, and ID of the VLAN to which the
interface is to be added
11.3.2 Enabling MLD snooping on the S9300
Context
To enable MLD snooping globally, do as follows on the S9300.
Procedure
Step 1 Run:
system-view

optimize the multicast forwarding table before enabling MLD snooping.
Step 3 Run:
mld-snooping enable
MLD snooping is enabled globally.
By default, MLD snooping is disabled on the S9300.
----End

11.3.3 Enabling MLD Snooping in a VLAN
Context
To enable MLD snooping in a VLAN, do as follows on the S9300.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
mld-snooping enable
MLD snooping is enabled in the VLAN.
When MLD snooping is disabled in a VLAN by default.
----End
11.3.4 (Optional) Adding an Interface to a Multicast Group

Statically
Context
To add an interface to a multicast group statically, do as follows on the S9300.
Procedure
Step 1 Run:
system-view
Step 2 Run the following commands as required:

l Run:

interface.
Step 3 Run:
mld-snooping static-group { group-ipv6-address [ source source-ipv6-address ]
vlan vlan-id }
The interface is added to a multicast group statically.

NOTE
l Before using the mld-snooping static-group command, ensure that the interface is added to the VLAN
specified by vlan-id; otherwise, the configuration fails.
l If the source-address parameter is specified in the mld-snooping static-group command, the MLD
version must be V2; otherwise, the configuration does not take effect even though the command can
be run.
----End
11.3.5 (Optional) Configuring an Interface as a Static Router

Interface
Context
To configure an interface as a static router interface, do as follows on the S9300.
Procedure
Step 1 Run:
system-view

Step 2 Run:

interface.
Step 3 Run:
mld-snooping static-router-port vlan vlan-id
The interface is configured as a static router interface.
NOTE
Before using the mld-snooping static-router-port vlan vlan-id command, ensure that the interface is
added to the VLAN specified by vlan-id; otherwise, the configuration fails.
----End
11.3.6 (Optional) Configuring the MLD Version
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
mld-snooping version version
The version is configured for MLD protocol packets that can be processed by MLD snooping.
The version can be set to 1 or 2.
By default, the S9300 can process MLDv1 packets.
----End
Procedure
Step 1 Run the display mld-snooping configuration command to check the configuration information
of MLD snooping.
Step 2 Run the display mld-snooping [ vlan vlan-id ] command to check the status of MLD snooping
in a VLAN.
Step 3 Run the display mld-snooping port-info [ vlan vlan-id [ group group-ipv6–address [ source-
address source-ipv6–address ] | verbose ] ] command to check information about member
interfaces of a multicast group and the router interface in a VLAN.
Step 4 Run the display mld-snooping router-port [ vlan vlan-id ] command to check information
about the router interface in a VLAN.
NOTE
The display mld-snooping port-info command displays only the information about the static member
interface or static router interface in Up state. If the static member interface or static router interface in
Down state, you can run the display mld-snooping configuration command to check the configuration
of the interface.
----End
11.4 Configuring a Multicast Group Policy for a VLAN

This section describes how to configure a multicast group policy for a VLAN.

You can configure policies to control the multicast groups that the hosts in a VLAN can join.
Before configuring a multicast group policy for a VLAN, complete the following task:
l 11.3 Enabling MLD Snooping
Data Preparation
To configure a multicast group policy for a VLAN, you need the following data.

No. Data
1 ID of the VLAN where the multicast group

policy is to be configured and number of the
interface connected to the multicast source in
the VLAN
2 (Optional) MLD version of the multicast

group policy
11.4.2 Configuring a Multicast Group Policy
Context
To configure a multicast group policy, do as follows on the S9300.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
mld-snooping group-policy acl-number [ mld-version ]
A multicast group policy is configured.
By default, no multicast group policy is available in a VLAN. That is, hosts in a VLAN can join
any multicast group. MLDv1/v2 is used.
Only a basic or advanced ACL6 can be used. Before configuring a multicast group policy, ensure
that an ACL6 has been created and a rule has been defined. For details, see Configuring ACL6.
NOTE
l When a multicast policy is configured for a VLAN, the multicast policy does not take effect if the
ACL6 specified by the ACL number does not exist; therefore, the hosts in the VLAN can join any
multicast group.
l If you run the undo acl ipv6 command to delete the ACL6 used by the multicast policy, hosts in the
VLAN can join any multicast group.
l A multicast policy is invalid for static multicast entries.
----End

Procedure
Step 1 Run the display mld-snooping [ vlan vlan-id ] [ configuration ] command to check the
configuration of MLD snooping in a VLAN.
Step 2 Run the display mld-snooping port-info [ vlan vlan-id [ group group-ipv6-address [ source-
address source-ipv6-address ] | verbose ] ] command to check the configuration of MLD
snooping on an interface.
----End
11.5 Configuring Prompt Leave of Interfaces

This section describes how to configure prompt leave of interfaces in a VLAN.
If each interface in a VLAN is connected to only one multicast receiver, you can enable prompt
leave on the interfaces to save bandwidth.
Before configuring the prompt leave function for interfaces in a VLAN, complete the following
tasks:
l Creating an ACL6
Data Preparation
To configure the prompt leave function for interfaces in a VLAN, you need the following data.
No. Data
1 ID of the VLAN where the prompt leave

function needs to be configured
11.5.2 Configuring Prompt Leave of Interfaces
Context
To configure the prompt leave function in a VLAN, do as follows on the S9300.
Procedure
Step 1 Run:
system-view


Step 2 Run:
vlan vlan-id

Step 3 Run:
mld-snooping prompt-leave [ group-policy acl-number ]
Prompt leave is enabled for interfaces in the VLAN.
NOTE
By default, no interface is allowed to promptly leave a multicast group.

If group-policy acl-number is not specified in step 3, the S9300 deletes the forwarding entry of a member
interface immediately when receiving a Done message from the interface.
----End
Procedure
If the configuration is successful, you can find that the prompt leave function is configured
correctly in the VLAN.
----End
11.6 Configuring the MLD Snooping Querier

This section describes how to configure the MLD snooping querier.

If a network does not have a Layer 3 multicast device, the MLD querier functions are unavailable
because the Layer 2 devices do not support MLD. To solve this problem, you can enable the
MLD snooping querier on the Layer 2 devices so that the Layer 2 devices can create and maintain
the IPv6 multicast forwarding entries at the data link layer. In this way, the IPv6 multicast data
can be forwarded at the data link layer.
Before configuring the MLD snooping querier on the VLAN, complete the following task:
l Enabling the MLD snooping function on the VLAN
Data Preparation
To configure the MLD snooping querier in a VLAN, you need the following data.

No. Data
1 Interval for sending MLD General Query

messages
2 Interval for sending MLD Group-Specific

Query messages
3 Maximum response time of the MLD General

Query message
4 Source IPv6 address of the MLD General

Query message
5 Source IPv6 address of the MLD Group-

Specific Query message
11.6.2 Enabling the MLD Snooping Querier

Context
Do as follows on the S9300.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
mld-snooping querier enable
The MLD snooping querier is enabled.
NOTE
By default, the MLD snooping querier is disabled.

The MLD snooping querier does not participate in the election of the MLD querier; however, the MLD
snooping querier on an IPv6 multicast network running MLD may affect the election result because the
source IPv6 address of the Query message sent by the MLD snooping querier is small.
----End

11.6.3 Setting the MLD Snooping Query Interval and Response

Interval
Context
The response time (max-response-time) of the MLD Snooping Query messages, including
General Query message and Group-Specific Query message, sent by the S9300 can be set
through commands. When a downstream device of the switch receives the Query message sent
by the switch, the downstream device starts a timer. When the timer value becomes 0, the
downstream device sends an MLD Snooping membership report message to the IPv6 multicast
group corresponding to the timer.
You should properly set the max-response-time parameter so that the switch can respond to the
MLD Snooping Query messages quickly. If the max-response-time is set improperly, a lot of
switches may send the membership report messages at the same time to congest the network
because the timers expire simultaneously.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
mld-snooping query-interval query-interval
The interval for sending the MLD Snooping General Query messages is set.
Step 4 Run:
mld-snooping max-response-time max-response-time
The maximum response time of the MLD Snooping General Query messages is set.
Step 5 Run:
mld-snooping last-listener-query-interval time-value
The interval for sending the MLD Snooping Specific-Group Query messages is set.
----End
11.6.4 Setting the Source IPv6 Address of MLD Query Messages

Context
Do as follows on the S9300.
Procedure
Step 1 Run:

system-view
Step 2 Run:
mld-snooping send-query source-address ipv6-address
The source IPv6 address of the MLD Query messages is set.
----End
Procedure
[Quidway]display mld-snooping vlan 95 configuration
MLD Snooping Configuration for VLAN 95
mld-snooping enable
mld-snooping version 2
Step 2 Run the display mld-snooping configuration command to view the global configuration of
MLD snooping.
[Quidway] display mld-snooping configuration
mld-snooping enable
mld-snooping group-policy 2000 2
mld-snooping enable
----End
11.7 (Optional) Modifying Parameters of MLD Snooping

This section describes how to optimize the performance of MLD snooping by modifying MLD
snooping parameters, including the aging time of the router interface, interval for sending Last
Member Query messages, interval for sending the General Query messages, maximum response
time for MLD messages, MLD robustness variable, source IP address of the MLD message sent
to respond to changes of Layer 2 network topology, MLD version, duration for suppressing the
same Report messages, maximum number of MLD snooping entries, and whether the Router
Alert option is contained in MLD messages.
You can modify parameters of MLD snooping to optimize the multicast performance on the
S9300 according to the actual situation of the network.
Before modifying parameters of MLD snooping, complete the following task:

Data Preparation
To modify parameters of MLD snooping, you need the following data.
No. Procedure
1 ID of the VLAN where you need to optimize

the performance of MLD snooping
2 (Optional) Aging time of the router interface
3 (Optional) Interval for sending Last Member

Query messages
4 (Optional) Interval for sending the General

Query messages
5 (Optional) Maximum response time of MLD

messages
6 (Optional) Robustness variable of the MLD
7 (Optional) Source IPv6 address of the MLD

General Query message that the MLD
snooping module sends to respond to the
change of the Layer 2 network topology
8 (Optional) Version of MLD messages that the

MLD snooping module can process in the
VLAN
9 (Optional) Duration for suppressing the same

MLD messages
10 (Optional) Number of MLD snooping entries

that can be configured or learned
11.7.2 (Optional) Setting the Aging Time of the Router Interface

Context
To set the aging time of the router interface, do as follows on the S9300.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
mld-snooping router-aging-time router-aging-time
The aging time of the router interface is set.
l By default, the S9300 sets the remaining aging time of router interface as follows:
l If the router interface receives an MLD Query message, the S9300 sets the remaining aging
time of the interface to 180 seconds.
l If the router interface receives a PIM Hello message and the holdtime value of the Hello
message is greater than the remaining aging time of the interface, the S9300 sets the remaining
aging time of the interface to the holdtime value.
----End
11.7.3 (Optional) Setting Parameters Related to the Aging Time of

Member Interfaces
Context
To set the parameters related to the aging time of member interfaces, perform the following steps
at a random order.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
mld-snooping query-interval query-interval
The interval for sending the General Query messages is set. The default value is 60 seconds.
Step 4 Run:
mld-snooping max-response-time max-response-time
The maximum response time of MLD messages is set. The default value is 10 seconds.
Step 5 Run:
mld-snooping robust-count robust-count
The robustness variable of MLD is set. The default value is 2.
----End

11.7.4 (Optional) Configuring the Router Alert Option in MLD

Messages
Context
To configure whether MLD messages contain the Router Alert option, do as follows on the
S9300.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
mld-snooping require-router-alert
The S9300 is configured to process only the MLD messages that contain the Router Alert option
in the IP header.
Step 4 Run:
mld-snooping send-router-alert
The S9300 is configured to send only the MLD messages that contain the Router Alert option
in the IP header.
By default, the S9300 processes all MLD messages and sends the MLD messages with the Router
Alert to the VLAN.
Step 3 and Step 4 are optional and can be performed in a random order.
----End
11.7.5 (Optional) Enabling the MLD Snooping Module to Respond

to Changes of the Layer 2 Network Topology
Context
To enable the MLD snooping module to respond to changes of the Layer 2 network topology,
do as follows on the S9300.
Procedure
Step 1 Run:
system-view

Step 2 Run:

mld-snooping send-query enable
The MLD snooping module of the S9300 is enabled to respond to changes of the Layer 2 network
topology.
Step 3 Run:
mld-snooping send-query source-address ipv6-address
The source IPv6 address of the MLD General Query messages that the MLD snooping module
sends to respond to changes of the Layer 2 network topology is set.
By default, the source IPv6 address of the MLD General Query message sent by the S9300 is
FE80::.
Step 3 is optional. After the S9300 is enabled to respond to changes of the Layer 2 network
topology, it sends an MLD General Query message to the downstream S9300 when receiving a
Topology Change message. Then the downstream S9300 can learn the new router interface.
When a member interface receives the MLD General Query message, the member interface
responds with an MLD Report message. Then the S9300 and its downstream S9300 can learn
the new multicast forwarding entry. This function enables the S9300 to forward multicast data
correctly after the Layer 2 topology changes.
----End
11.7.6 (Optional) Setting the Duration for Suppressing the Same

MLD Messages
Context
To set the duration for suppressing the MLD Report messages with the same content, do as
follows on the S9300.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mld-snooping suppression-time time-value
The duration for suppressing the same MLD Report messages is set.
NOTE
l By default, the duration for suppressing the same MLD Report messages is 10 seconds.
l The MLD snooping function is applicable to only the MLDv1 packets, but is invalid for the MLDv2
packets.
----End

Procedure
Step 1 Run the display mld-snooping [ vlan vlan-id ] command to check information about MLD
snooping in a VLAN.
----End
Example
If the preceding configurations are successful, the following information is displayed:
<Quidway> display mld-snooping vlan 10
MLD Snooping Vlan Information for VLAN 10
MLD Snooping is Enable
MLD Version is Set to default 1
MLD Query Interval is Set to default 125
MLD Max Response Interval is Set to default 10
MLD Robustness is Set to default 2
MLD Last Member Query Interval is Set to default 1
MLD Router Port Aging Interval is Set to 180s or holdtime in hello
MLD Filter Group-Policy is Set to default : Permit All
MLD Prompt Leave Disable
MLD Router Alert is Not Required
MLD Send Router Alert Enable
MLD Snooping Querier Disable
11.8 Maintaining MLD Snooping

This section describes how to maintain MLD snooping.
11.8.1 Clearing MLD Snooping Entries
Context
CAUTION
Use this command with caution. After the MLD snooping entries, that is, the dynamic forwarding
entries, of a VLAN are deleted from the multicast forwarding table, the multicast flows sent to
hosts in the VLAN are interrupted. The hosts can receive multicast flows again only after the
S9300 receives the MLD Membership Report messages from the hosts and generates new
forwarding entries.
To clear the dynamic forwarding entries from the multicast forwarding table, run the following
command in the user view.
Procedure
Step 1 Run the reset mld-snooping group { vlan { vlan-id | all } | all } command to clear the dynamic
forwarding entries from the multicast forwarding table.
----End

11.8.2 Clearing the Statistics on MLD Snooping
Context
CAUTION
The statistics on MLD snooping cannot be restored after you clear them. So, confirm the action
before you use the command. To clear the statistics on MLD snooping, run the following
command in the user view.
Procedure
Step 1 Run the reset mld-snooping statistics [ vlan vlan-id ] command to clear the statistics on MLD
snooping in a VLAN.
----End
11.8.3 Debugging MLD Snooping
Context
CAUTION
mld-snooping all command to disable it immediately.
When a fault occurs in MLD Snooping, you can run the following debugging command in the
user view to debug MLD snooping and locate the fault.
Procedure
Step 1 Run the debugging mld-snooping [ all | event | done [ basic-acl-number ] | packet [advance-
acl-number ] | query [ advance-acl-number ] | report [ advance-acl-number ] | timer |
general ] command in the user view to enable debugging of MLD snooping.
----End

This section provides several configuration examples of MLD snooping.
11.9.1 Example for Configuring a Multicast Group Policy

As shown in Figure 11-1, three hosts are all in VLAN 3. All these three hosts need to receive
data from multicast groups FF32::1 to FF32::10.
Figure 11-1 Networking diagram for configuring a multicast group policy on the Ethernet
DHCP server multicast source
IP/MPLS core
GE1/0/6
SwitchA
VLAN 3
GE1/0/5
Host 3 Host 4 Host 5
1. Create VLAN 3 and add GE 1/0/5 and GE 1/0/6 to VLAN 3.
2. Enable MLD snooping globally on SwitchA.
3. Configure a multicast group policy in VLAN 3 on SwitchA.
4. Enable MLD snooping in VLAN 3 on SwitchA.
Data Preparation
l VLAN that Host 3, Host 4, and Host 5 belong to: VLAN 3
l Multicast groups that Host 3, Host 4, and Host 5 can join: FF32::1 to FF32::10
Procedure
Step 1 Create VLAN 3 on SwitchA and add GE 1/0/5 and GE 1/0/6 to VLAN 3. The configuration
procedure is not provided here.
Step 2 Enable MLD snooping globally on SwitchA.

[SwitchA]mld-snooping enable
Step 3 Create an IPv6 ACL.

[SwitchA]acl ipv6 3000
[SwitchA-acl6-adv-3000] rule permit ipv6 source FF32::3 128
[SwitchA-acl6-adv-3000] quit
Step 4 Configure a multicast group policy in VLAN 3.

[SwitchA] vlan 3
[SwitchA-vlan3] mld-snooping group-policy 3000
Step 5 Enable MLD snooping in VLAN 3.

[SwitchA-vlan3] mld-snooping enable

# Verify that host 3, host 4 and host 5 can join multicast groups FF32::1 to FF32::10. Send
Membership Report messages from Host 3, Host 4, or Host 5 to multicast group FF32::3, and
then run the display mld-snooping port-info on SwitchA. You can view information about the
outgoing interface of the multicast group.
[SwitchA-vlan3] display mld-snooping port-info
-----------------------------------------------------------------------
-----------------------------------------------------------------------
VLAN 3, 1 Entry(s)
( *, FF32::3) GE1/0/5 S--
1 port(s)
-----------------------------------------------------------------------
The preceding output shows that GE 1/0/5 has joined multicast group FF32::3.
# Verify that host 3, host 4 and host 5 cannot join multicast groups out of the range of FF32::1
to FF32::10.
Send Membership Report messages from Host 15, Host 4, or Host 5 to multicast group FF32::15,
and then run the display mld-snooping port-info on SwitchA. You can view information about
the outgoing interface of the multicast group.
[Switch-vlan3] display mld-snooping port-info
Source/Group LiveTime Port-Count Port-Flag
-----------------------------------------------------------------------
Vlan 3, 1 Entry(s)
( *, FF32::3) 00:00:32 2
GigabitEthernet1/0/5 D
No information about the outgoing interface of multicast group FF32::15 is displayed. It

indicates that GE 0/0/5 does not join the multicast group FF32::15.
----End
Configuration Files
#
sysname SwitchA
#
mld-snooping enable
#
vlan batch 3
#

vlan 3
mld-snooping enable
mld-snooping group-policy 3000
multicast drop-unknown
#
acl ipv6 number 3000
rule 5 permit ipv6 source FF32::3/128
#
interface Gigabitethernet 1/0/5
#
interface Gigabitethernet 1/0/6
#
return
11.9.2 Example for Configuring Prompt Leave of Interfaces in a

VLAN
As shown in Figure 11-2, GE 1/0/3 and GE 1/0/4 on of Switch A are connected to only one
receiver respectively. Other hosts connected to GE 1/0/3 and GE 1/0/4 do not need to receive
multicast packets. Therefore, when receiving MLD Leave messages from the two interfaces,
Switch A deletes the forwarding entries of the multicast groups that the hosts leave without
waiting for the timeout of the aging timer. This saves the bandwidth and system resources.
Figure 11-2 Networking diagram for configuring prompt leave of interfaces in a VLAN
IP/MPLS
core
GE1/0/5
SwitchA
GE1/0/3 GE1/0/4
VLAN 3
Host1 Host2 Host 3 Host 4 Host 5

1. Create VLAN 3 on Switch A and add GE 1/0/3, GE 1/0/4, and GE 1/0/5 to VLAN 3.
2. Enable MLD snooping globally on Switch A.
3. Enable prompt leave of interfaces in VLAN 3 on Switch A.
4. Enable MLD snooping in VLAN 3 on Switch A.
Data Preparation
l ID of the VLAN where prompt leave is enabled: 3
Procedure
Step 1 Create VLAN 3 on Switch A and add GE 1/0/3, GE 1/0/4, and GE 1/0/5 to VLAN 3. The
configuration procedure is not provided here.
Step 2 Enable MLD snooping globally on Switch A.
[SwitchA] mld-snooping enable
Step 3 Enable prompt leave of interfaces in VLAN 3.

[SwitchA] vlan 3
[SwitchA-vlan3] mld-snooping prompt-leave

Step 5 Verify the configuration. Run the display mld-snooping command on Switch A.
[SwitchA] display mld-snooping vlan 3
MLD Snooping Vlan Information for VLAN 3
MLD Snooping is Enable
MLD Version is Set to default 1
MLD Query Interval is Set to default 60
MLD Max Response Interval is Set to default 10
MLD Robustness is Set to default 2
MLD Last Listener Query Interval is Set to default 1
MLD Router Port Aging Interval is Set to 180s or holdtime in hello
MLD Filter Group-Policy is Set to default : Permit All
MLD Prompt Leave enable
MLD Router Alert is Not Required
MLD Send Router Alert Enable
As shown in the preceding output, "MLD Prompt Leave enable" indicates that the configuration
of prompt leave for interfaces in VLAN 3 is successful.
----End
Configuration Files
#
sysname SwitchA
#
mld-snooping enable
#
vlan batch 3
#
vlan 3

mld-snooping enable
mld-snooping prompt-leave
#
interface Gigabitethernet1/0/3
port default vlan 3
#
port default vlan 3
#
port default vlan 3
#
return
11.9.3 Example for Configuring a Static Router Interface
As shown in Figure 11-3, Switch A is connected to a router and several hosts. The router runs
the MLD protocol. The Switch A needs to forward multicast data to the hosts.
Figure 11-3 Networking diagram for configuring a static router interface

IP/MPLS core
GE1/0/5
VLAN 2
SwitchA
GE1/0/2
GE1/0/3
Host 1 Host 2
1. Create VLAN 2 on Switch A and add GE 1/0/2, GE 1/0/3, and GE 1/0/5 to VLAN 2.
2. Enable MLD snooping globally on Switch A.
3. Configure GE 1/0/5 as a static router interface.

4. Enable MLD snooping in VLAN 2 on Switch A.
Data Preparation
l Interface to be configured as a static router interface: GE 1/0/5
l VLAN that Host 1 and Host 2 belongs to: VLAN 2
Procedure
Step 1 Create VLAN 2 on Switch A and add GE 1/0/2, GE 1/0/3, and GE 1/0/5 to VLAN 2. The
configuration procedure is not provided here.
Step 2 Enable MLD snooping globally on Switch A.

[SwitchA] mld-snooping enable

Step 4 Configure GE 1/0/5 as a static router interface.

[SwitchA-GigabitEthernet1/0/5] mld-snooping static-router-port vlan 2
Step 5 Verify the configuration. Run the display mld-snooping router-port command on Switch A.
[SwitchA] display mld-snooping router-port vlan 2
Total Number of Router Port on Vlan 2 is 1
GE1/0/5 00:00:32 -- STATIC
The preceding output shows that GE 1/0/5 is configured as a static router interface.
----End
Configuration Files
#
sysname SwitchA
#
mld-snooping enable
#
vlan batch 2
#
vlan 2
mld-snooping enable
#
port default vlan 2
#
port default vlan 2
#
port default vlan 2
mld-snooping static-router-port vlan 2
#
return

11.9.4 Example for Enabling the MLD Snooping Module to

Respond to Changes of the Layer 2 Network Topology
As shown in Figure 11-4, four S9300s form a ring network to improve the network reliability.
To prevent loops on the network, the S9300s run the Multiple Spanning Tree Protocol (MSTP).
Host 1 and Host 2 need to receive multicast data from the multicast source. The IPv6 addresses
of Host 1 and Host 2 are 2::3/112 and 3::1/64 respectively.
Figure 11-4 Networking diagram for enabling the MLD snooping module to respond to changes
of the Layer 2 network topology
IP/MPLS
core
GE1/0/3
SwitchA
GE1/0/1 GE1/0/2
MSTP SwitchD
SwitchC
GE1/0/5 GE1/0/7 GE1/0/2
GE1/0/6 GE1/0/8
SwitchB
GE1/0/3 GE1/0/4
GE1/0/1 3::1/64
Host2
VLAN 3
2::3/112
Host1
1. Enable MSTP on all the S9300s.
2. Create VLAN 3 and add interfaces to VLAN 3 on all the S9300s.
3. Enable MLD snooping globally on all the S9300s.

4. Enable MLD snooping in VLAN 3 on all the S9300s.

5. Enable the MLD snooping module of SwitchA to respond to changes of the Layer 2 network
topology.
Data Preparation
l Source IP address contained in the MLD General Query message that the MLD snooping
module sends to respond to changes of the Layer 2 network: FE80::1
Procedure
Step 1 Enable MSTP on all the S9300s. The configuration procedure is not provided here. For the
method of configuring MSTP, see the Quidway S9300 Terabit Routing Switch Configuration
Guide - Ethernet.
Step 2 Create VLAN 3 and add interfaces to VLAN 3 on all the S9300s. The configuration procedure
is not provided here.
Step 3 Run the mld-snooping enable command to enable MLD snooping globally on all the S9300s.
Step 4 Enable MLD snooping in VLAN 3 on all the S9300s.
[SwitchA] vlan 3
The configurations of other S9300s are similar to the configuration of SwitchA, and are not
provided here.
Step 5 Enable the MLD snooping module of SwitchA to respond to changes of the Layer 2 network
topology.
[SwitchA]mld-snooping send-query enable
[SwitchA] mld-snooping send-query source-address FE80::1

l Verify that Host 1 and Host 2 can receive multicast data.
l Run the display stp command on the S9300s to find the interfaces that are blocked and the
transmission path of multicast data.
l Assume that GE 1/0/1 is blocked and multicast data is transmitted to Host 1 through the path
SwitchA -> SwitchC -> SwitchB and to Host 2 through the path SwitchA -> SwitchD. Run
the shutdown command on GE 1/0/1 of SwitchC to shut down the interface so that the
topology of the MSTP network changes.
l Verify that Host 1 and Host 2 can still receive multicast data after the network topology
changes.
----End
Configuration Files
Configuration file of SwitchA
#
sysname SwitchA
#
mld-snooping enable
mld-snooping send-query enable

mld-snooping send-query source-address FE80::1

#
vlan batch 3
#
stp enable
#
vlan 3
mld-snooping enable
#
bpdu enable
#
bpdu enable
#
bpdu enable
#
return
Configuration file of SwitchB

#
sysname SwitchB
#
mld-snooping enable
#
vlan batch 3
#
stp enable
#
vlan 3
mld-snooping enable
#
port default vlan 3
bpdu enable
#
bpdu enable
#
bpdu enable
#
return
Configuration file of SwitchC

#
sysname SwitchC
#
mld-snooping enable
#
vlan batch 3
#
stp enable
#
vlan 3
mld-snooping enable
#

bpdu enable
#
bpdu enable
#
return
Configuration file of SwitchD

#
sysname SwitchD
#
mld-snooping enable
#
vlan batch 3
#
stp enable
#
vlan 3
mld-snooping enable
#
port default vlan 3
bpdu enable
#
bpdu enable
#
bpdu enable
#
return

12 PIM-DM (IPv6) Configuration
About This Chapter
The PIM protocol can be used in an IPv6 network to implement multicast routing and data
forwarding inside an AS. The PIM-DM protocol is a multicast routing protocol of dense node.
It is applicable to a small-scale network with densely-distributed members.
12.1 PIM-IPv6 Overview
In the IPv6 network where multicast group members are densely distributed and each network
function to enhance the IPv6 PIM-DM security.
12.3 Configuring Basic PIM-DM (IPv6) Functions
IPv6 PIM-DM on each interface of the multicast device. In this manner, the IPv6 PIM-DM
network can work normally.
12.4 Adjusting Control Parameters of a Source
12.5 Adjusting Control Parameters for Maintaining Neighbors
requesting the upstream device to execute the prune operation. If other downstream devices on
the same network segment need the multicast data for this group, they need to send Join messages
to override the prune operation. You can adjust control parameters of Join/Prune messages as


can enable the State-Refresh function to enable the multicast device to send State-Refresh
messages periodically, refresh the prune state of the interface, and maintain SPT.
12.8 Adjusting Control Messages for Graft
To enable new members in a network to quickly receive multicast data, a multicast device
actively sends a Graft message through an upstream interface, requesting the upstream device
to forward multicast data to this network segment.
12.9 Adjusting Control Messages for Assert
device.
12.10 Configuring PIM-IPv6 Silent
12.11 Maintaining PIM-DM
Maintaining IPv6 PIM-DM involves resetting PIM statistics, and monitoring PIM running status.
Configuration examples are provided to show how to construct a basic IPv6 PIM-DM network.


In the IPv6 network where multicast group members are densely distributed and each network
In IPv4 multicast applications, the Protocol Independent Multicast (PIM) is used to establish
multicast routes between switchs to replicate and forward multicast packets.
In IPv6 multicast applications, switchs run PIM-IPv6. The functions and principles of PIM-IPv6
are similar to those of PIM-IPv4.
PIM-IPv6 consists of the following separate protocols:
l PIM-DM: indicates the Protocol Independent Multicast-Dense Mode. PIM-DM is

applicable to a small-scale network with densely-distributed members. The network adopts
the Any-Source Multicast (ASM) model to implement multicast services.
l PIM-SM: indicates the Protocol Independent Multicast-Sparse Mode. PIM-SM is
applicable to a large-scale network with sparsely-distributed members. The network adopts
the ASM and Source-Specific Multicast (SSM) models to implement multicast services.
NOTE
l This chapter is concerned only about the PIM-DM configuration in the IPv6 network. PIM-DM in this
chapter refers to IPv6 PIM-DM, unless otherwise specified.
l For details of PIM-SM (IPv6), refer to the chapter PIM-SM (IPv6) Configuration.
l For details of ASM and SSM models, refer to the chapter "IP Multicast Overview" in the Quidway
S9300 Terabit Routing Switch Feature Description - IP Multicast.

function to enhance the IPv6 PIM-DM security.
Controlling the Forwarding of a Multicast Source

You can configure the Keepalive period of a multicast source and the filtering rules of the
multicast source.
Adjusting Control Parameters for Maintaining Neighbors

You can set the following control parameters by using the related commands:

l Period for keeping neighbors reachable
l Whether the Hello messages without the Generation ID option are accepted
l Maximum delay for triggering Hello messages

rules
Adjusting Control Parameters for Pruning

You can adjust the following control parameters for pruning:
l The interval for keeping the Prune state of the downstream interface
l The delay from the time when the current switch receives a Prune message from a
downstream switch to the time when the current switch performs the prune action in the
LAN
l The period for overriding the prune action
Adjusting Control Parameters for State-Refresh

You can enable or disable State-Refresh, set the interval for sending PIM State-Refresh
messages, set the time for waiting to receive the next State-Refresh message, and set the TTL
values of State-Refresh messages.
Adjusting Control Parameters for Graft

You can set the interval for retransmitting Graft messages.

You can set the period for switchs to keep the Assert state. The switchs that fail in the election
forbid downstream interfaces to forward multicast data during this period. After the period
expires, the downstream interfaces continue to forward multicast data.

Some hosts may send a large number of malicious PIM Hello messages, which results in the
suspension of the switch. By configuring the PIM Silent function on the interfaces of the
switch connected with the host, you can protect the switch from being attacked.
12.3 Configuring Basic PIM-DM (IPv6) Functions

IPv6 PIM-DM on each interface of the multicast device. In this manner, the IPv6 PIM-DM

Before configuring basic IPv6 PIM-DM functions, configure a unicast IPv6 routing protocol.
PIM-DM is applicable to a small-scale network. Most of network segments have receivers.

Before configure basic PIM-DM functions, complete the following tasks:
Data Preparation
To configure basic PIM-DM functions, you need the following data.
No. Data
1 Type and number of the interface to be enabled with PIM-DM (IPv6)

Context
Procedure
Step 1 Run:
system-view

Step 3 Run:
The IPv6 multicast routing is enabled in the public network instance.
----End
12.3.3 Enabling Basic PIM-DM (IPv6) Functions

An interface can set up IPv6 PIM neighbor relationship with other devices after IPv6 PIM-DM
is enabled on it.
Context

Procedure
Step 1 Run:
system-view
Step 2 Run:
The VLANIF interface view is displayed.
Step 3 Run:
pim ipv6 dm
Basic PIM-DM (IPv6) functions are enabled.
After PIM-DM (IPv6) is enabled on interfaces, switchs set up the PIM-IPv6 neighbor
relationship with each other. The switchs can then process protocol packets received from PIM-
IPv6 neighbors.
You can run the undo pim ipv6 dm command to disable PIM-DM (IPv6) on an interface.
NOTE
PIM-DM (IPv6) and PIM-SM (IPv6) cannot be enabled on an interface simultaneously. The PIM-IPv6
modes on all interfaces that belong to the same instance must be the same. When a switch is deployed in
a PIM-DM (IPv6) domain, enable PIM-DM (IPv6) on all non-boundary interfaces.
----End

After IPv6 PIM-DM is configured successfully, you can check information about the PIM
interface, PIM neighbor, and PIM routing table through commands..
Procedure
l Run the display pim ipv6 interface [ interface-type interface-number | up | down ]
[ verbose ] command to check information about PIM-IPv6 interfaces.
l Run the display pim ipv6 neighbor [ ipv6-link-local-address | interface interface-type
interface-number | verbose ] * command to check information about PIM-IPv6 neighbors.
l Run the following commands to check the PIM-IPv6 multicast routing table.
– display pim ipv6 routing-table [ ipv6-source-address [ mask mask-length ] | ipv6-
group-address [ mask mask-length ] | flags { act | del | exprune | ext | loc | niif |
nonbr | none | rpt | sg_rcvr | sgjoin | spt | swt | wc | upchg } | fsm | incoming-
interface { interface-type interface-number | register } | mode { dm | sm | ssm } |
outgoing-interface { exclude | include | match } { interface-type interface-number |
none | register } ] * [ outgoing-interface-number [ number ] ]
– display pim ipv6 routing-table brief [ ipv6-source-address [ mask mask-length ] |
ipv6-group-address [ mask mask-length ] | incoming-interface { interface-type
----End



After basic functions of IPv6 PIM-DM are configured, you can configure the lifetime of a
multicast source and source address-based filtering rules as required.
This configuration is applicable to all PIM-DM networks.
PIM-IPv6 switchs check the passing multicast data packets. By checking whether the data
packets match the filtering rule, the switchs determine whether to forward the packets. That is,
the switchs in the PIM-IPv6 domain act as filters. The filters help to control data flows and limit
information obtained by downstream receivers.
Before adjusting control parameters of a source, complete the following tasks:
l Configuring Basic PIM-DM (IPv6) Functions
Data Preparation
To adjust control parameters of a source, you need the following data.
No. Data
1 Keepalive period of a source
12.4.2 Configuring the Keepalive Period of a Source

Context
Do as follows on the PIM-IPv6 switch:
NOTE

Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
The PIM-IPv6 view is displayed.
Step 3 Run:
The Keepalive period of a source is configured.
If a switch does not receive any (S, G) packet in the Keepalive period of the source, the
switch considers that the source stops sending multicast data to G, and the (S, G) entry becomes
invalid.
----End

After ACL6 rules are configured, a multicast device can filter the received multicast packets
based on source addresses or source/group addresses.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
source-policy { acl6-number | acl6-name acl6-name }
The nearer the filter to the source, the more obvious the effect of the filtering.
are forwarded.

NOTE
l If acl6-number | acl6-name acl6-name is specified in the source-policy command and ACL rules are
l If acl6-number | acl6-name acl6-name is specified in the source-policy command and no ACL rule is
l The source-policy command does not filter the static (S, G) entries.
----End

Procedure
----End
12.5 Adjusting Control Parameters for Maintaining

Neighbors

After basic functions of IPv6 PIM-DM are configured, you can adjust related parameters of the
Hello message for controlling the neighbor relationships and configure the neighbor filtering
function to enhance security as required.
PIM-IPv6 switchs establish the neighbor relationship by exchanging Hello messages to negotiate
various control parameters.
Switchs under the control of default values can work normally. In the S9300, users can adjust
NOTE

Before adjusting control parameters for maintaining neighbors, complete the following tasks:

Data Preparation
To adjust control parameters for maintaining neighbors, you need the following data.
No. Data
1 Timeout period for waiting to receive Hello message from neighbors
12.5.2 Configuring the Interval for Sending Hello Messages

Context
NOTE
The configuration of the control parameters for maintaining PIM-IPv6 neighbors involves the following
cases:
configuration. If the configuration on an interface is not set, the global configuration is used.
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:

The interval for sending Hello messages is configured.

1. Run:
system-view

2. Run:

3. Run:
pim ipv6 timer hello interval

4. Run:
pim ipv6 triggered-hello-delay interval
After the maximum delay is set, the conflict caused by multiple PIM-IPv6 switchs
simultaneously sending Hello message is avoided.
----End
12.5.3 Configuring the Timeout Period of a Neighbor

Context
NOTE
The configuration of the control parameters for maintaining PIM-IPv6 neighbors involves the following
cases:
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:
The timeout period for keeping a neighbor reachable is set.

Each switch maintains a timer for each neighbor. When receiving a Hello message, a
switch resets the timer. If the local switch does not receive any Hello message from
a neighbor after the timer times out, the local switch considers that the neighbor is
unreachable.
1. Run:
system-view

2. Run:

3. Run:
pim ipv6 hello-option holdtime interval
The timeout period for keeping the neighbor reachable is set.

If the local switch does not receive any Hello message from a neighbor after the timer
times out, the local switch considers that the neighbor is unreachable.
----End
12.5.4 Refusing to Receive the Hello Message Without the

Generation ID Option
Context
A switch assigns a random Generation ID to an interface enabled with PIM. The Hello messages
sent by the interface carry the random Generation ID. If the status of the interface changes, the
random Generation ID is updated.
changes, it indicates that the status of the upstream neighbor changes. If a switch does not want
to receive data from an upstream neighbor, the switch sends a Prune message after receiving a
data packet from the upstream neighbor.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
pim ipv6 require-genid
The Generation ID option is set in a Hello message.
The Hello message without the Generation ID option is rejected.
----End

Context
To prevent some switch from being involved in PIM, filtering PIM neighbors is required.
Do as follows on the switch running IPv6 PIM-DM:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim ipv6 neighbor-policy { basic-acl6-number | acl6-name acl6-name }
NOTE
----End


Procedure
----End

requesting the upstream device to execute the prune operation. If other downstream devices on
the same network segment need the multicast data for this group, they need to send Join messages
to override the prune operation. You can adjust control parameters of Join/Prune messages as

After basic IPv6 PIM-DM functions are configured, you can set the period for an interface to
keep the prune state, delay for transmitting Prune messages in a LAN, and interval for overriding
the prune action as required.
When the last member of a group on a switch leaves its group, the switch sends a Prune message
through an upstream interface to request the upstream switch to perform the prune action. After
receiving the Prune message, the upstream interface stops forwarding packets to this network
segment. If other downstream switchs exist in this network segment, they must send the Join
message to override the prune action.
Before adjusting control parameters for prune, complete the following tasks:
Data Preparation
To adjust control parameters for prune, you need the following data.
No. Data
3 Period for overriding the prune action

12.6.2 Configuring the Period for an Interface to Keep the Prune

State
The period for an interface to keep the prune state can be set either globally or on an interface.
After the period expires, the pruned interface starts to forward messages again. If the multicast
device receives a State-Refresh message before the period expires, it resets the timer, that is, it
refreshes the prune state.
Context
NOTE
The configuration of the control parameters of prune involves the following cases:
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:
After the period expires, the pruned interface continues to forward packets. Before
the period expires, the switch resets the Holdtime timer after receiving a State-Refresh
message.
1. Run:
system-view

2. Run:

3. Run:
pim ipv6 holdtime join-prune interval

After the period expires, the pruned interface continues to forward packets. Before
the period expires, the switch resets the Holdtime timer after receiving a State-Refresh
message.
----End
12.6.3 Configuring the Delay for Transmitting Prune Messages in a

LAN
The delay for transmitting Prune messages in a LAN can be set either globally or on an interface.
When the values of lan-delay on all devices along the same link are different, the maximum
value of these values is preferred.
Context
The Hello message carries lan-delay and the override-interval. The relationship between lan-
delay, override-interval, and Prune-Pending Timer (PPT) is that lan-delay + override-interval =
PPT. PPT indicates the delay from the time when a switch receives the Prune message from a
downstream interface to the time when the switch performs the prune action to suppress the
forwarding on the downstream interface. If the switch receives a Join message from a
downstream switch within the PPT, the switch does not perform the prune action.
NOTE
The configuration of control parameters for Prune involves the following two cases:
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:

1. Run:
system-view

2. Run:


3. Run:
pim ipv6 hello-option lan-delay interval
----End
12.6.4 Configuring the Interval for Overriding the Prune Action

If a device receives a Prune message from the upstream interface, it indicates that other
downstream devices still exist in the LAN. If these devices still needs to receive the multicast
data, the device must send a Join message upstream within the override-interval.
Context
When a switch receives a Prune message from an upstream interface, it indicates that switch in
the LAN. When a switch receives a Prune message from an upstream interface, it indicates that
the switch still needs to receive multicast data. If the switch still requests the multicast data, it
needs to send a Join message in the override-interval period to the upstream switch.
NOTE
The configuration of control parameters for Prune involves the following two cases:
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:

1. Run:
system-view

2. Run:

3. Run:
pim ipv6 hello-option override-interval interval

----End

After the control parameters for prune are adjusted, you can check information about the PIM
commands.
Procedure
l Run the display pim ipv6 control-message counters [ message-type { assert | graft |
graft-ack | hello | join-prune | state-refresh | bsr } | interface interface-type interface-
number ] * command to check the number of sent and received PIM-IPv6 control messages.
----End

can enable the State-Refresh function to enable the multicast device to send State-Refresh
messages periodically, refresh the prune state of the interface, and maintain SPT.
12.7.1 Estalishing the Configuration Task

After basic functions of IPv6 PIM-DM are configured, you can set the interval for sending State-
Refresh messages, period for waiting to receive the next State-Refresh message, and TTL value
carried in the State-Refresh message as required.
By default, a PIM-DM interface is in the forwarding state. The pruned interface continues to
forward packets after the prune timer times out. In the PIM-DM network, periodically flooding
State-Refresh messages can update the prune timer and maintain the suppressed state of the
prune interface.

NOTE
Before adjusting control parameters for State-Refresh, complete the following tasks:
Data Preparation
To adjust control parameters for State-Refresh, you need the following data.
No. Data
1 Interval for sending PIM State-Refresh messages
2 Period for waiting to receive the next State-Refresh message
3 TTL value used to forward State-Refresh messages
12.7.2 Disabling State-Refresh

After this function is disabled on the interface, the interface cannot forward any State-Refresh
messages.
Context
Do as follows on all switchs in the PIM-DM domain:
NOTE
By default, PIM-DM State-Refresh is enabled on an interface.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
undo pim ipv6 state-refresh-capable
State-Refresh is disabled.

The interface on which PIM-DM State-Refresh is disabled cannot forward any State-Refresh
message.
NOTE
You can run the pim ipv6 state-refresh-capable command to re-enable the PIM-DM State-Refresh on the
interface.
----End
12.7.3 Configuring the Interval for Sending State-Refresh Messages

To prevent pruned interfaces from forwarding messages after the prune state timer times out,
you need to set the interval for sending State-Refresh messages to be shorter than the period for
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
state-refresh-interval interval
The interval for sending PIM-IPv6 State-Refresh messages is set.
NOTE
The interval for sending PIM State-Refresh messages should be shorter than the timeout period for keeping
the Prune state. You can run the holdtime join-prune command to set the timeout period for keeping the
Prune state.
----End
12.7.4 Configuring the Period for Receiving the Next State-Refresh

Message
A multicast device may receive PIM State-Refresh messages from multiple routers in a short
period and some PIM State-Refresh messages are repeated. Before the state-refresh timer times
out, the device discards the received repeated State-Refresh messages. The device is allowed to
receive the next State-Refresh message only after the timer times out.
Context

Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
state-refresh-rate-limit interval
The period for waiting to receive the next State-Refresh message is set.
----End
12.7.5 Configuring the TTL Value of a State-Refresh Message

After receiving the PIM State-Refresh message, a multicast device decrements the TTL value
by 1 and then forwards the message downstream until the TTL value becomes 0. In a small-
sized network, the PIM State-Refresh message is transmitted circularly on the network. You can
adjust the TTL value according to the network scale.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
state-refresh-ttl ttl-value
The TTL value in the State-Refresh message is set.
----End

After the control parameters for state-refresh are adjusted, you can check information about the
PIM interface and the PIM routing table and statistics about PIM control messages through
commands.

Procedure
----End
12.8 Adjusting Control Messages for Graft

To enable new members in a network to quickly receive multicast data, a multicast device
actively sends a Graft message through an upstream interface, requesting the upstream device
to forward multicast data to this network segment.

After basic functions of IPv6 PIM-DM are configured, you can set the interval for retransmitting
Graft messages as required.
In the PIM-DM network, if State-Refresh is not enabled, the pruned interface can forward
packets only after the Prune timer times out. If State-Refresh is enabled, the pruned interface
may not continue to forward packets forever.
To enable new members in the network to quickly receive multicast data, the PIM-DM switch
sends a Graft message through an upstream interface. After receiving the Graft message, the
upstream switch immediately replies a Graft-Ack message and restores the forwarding of the
interface that receives the Graft message.
switchs in the control of default values can work normally. In the S9300, users can adjust related
parameters according to the specific network environment.
NOTE
Before adjusting control parameters for graft, complete the following tasks:


Data Preparation
To adjust control parameters for graft, you need the following data.
No. Data
1 Interval for retransmitting Graft messages
12.8.2 Setting the Interval for Retransmitting Graft Messages

In PIM-DM mode, when a member joins a pruned group, the multicast device sends a Graft
message and waits for an ACK message from the upstream device. If the downstream device
does not receive any ACK message within a certain period, the device resends the Graft message
until it receives an ACK message from the upstream device.
Context
If the local switch does not receive any Graft-Ack message from the upstream switch in the
specified time, the local switch resends the Graft message.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim ipv6 timer graft-retry interval
The interval for retransmitting Graft messages is set.
----End

After the control parameters for graft are adjusted, you can check information about the
unacknowledged PIM-DM graft, PIM interface, and PIM routing table and statistics about PIM
control messages through commands.

Procedure
l Run the display pim ipv6 grafts command to check the unacknowledged PIM-DM Graft
messages.
----End
12.9 Adjusting Control Messages for Assert

device.

After basic functions of IPv6 PIM-DM are configured, you can set the period for holding the
Assert state as required.
When a PIM-DM switch receives multicast data through a downstream interface, this indicates
that other upstream switchs exist in this network segment. The switch sends an Assert message
through the downstream interface to take part in the assert election.
Switchs in the control of default values can work normally. In the S9300, users can adjust related
parameters according to the specific network environment.
NOTE
Before adjusting control parameters for Assert, complete the following tasks:

Data Preparation
To adjust control parameters for asset, you need the following data.
No. Data
1 The period for keeping the Assert state

data. After the holdtime of the Assert state expires, the downstream interface can forward
multicast data.
Context
NOTE

Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:
The period for keeping the Assert state is set.
The switch that fails in the election prohibits its downstream interface from forwarding
multicast data.
After the Holdtime timer times out, the downstream interface continues to forward
packets.
1. Run:
system-view


2. Run:

3. Run:
pim ipv6 holdtime assert interval
The switch that fails in the election prohibits its downstream interface from forwarding
multicast data.
After the Holdtime timer times out, the downstream interface continues to forward
packets.
----End

commands.
Procedure
----End



After basic functions of IPv6 PIM-DM and MLD are configured, you can configure the PIM
silent function on the interface connected with the user host. This interface should be enabled
with IPv6 PIM-DM and MLD first.
At the access layer, the switch interface directly connected to hosts needs to be enabled with
PIM-IPv6. You can establish a PIM-IPv6 neighbor on the switch interface to process various
PIM packets. The configuration, however, has the security vulnerability. When a host
maliciously generates PIM-IPv6 Hello packets and sends the packets in a large quantity, the
switch may break down.
To avoid the preceding case, you can set the status of the switch interface to PIM silent. When
the interface is in the PIM-IPv6 silent state, the interface is prohibited from receiving and
forwarding any PIM-IPv6 packet. All PIM-IPv6 neighbors and PIM-IPv6 state machines on the
interface are deleted. The interface then acts as the static DR, which takes effect immediately.
At the same time, MLD on the interface is not affected.
PIM silent is applicable only to the switch interface directly connected to the host network
segment that is connected only to this switch.
CAUTION
If PIM-IPv6 silent is enabled on the interface connected to a switch, the PIM-IPv6 neighbor
If the host network segment is connected to multiple switchs and PIM-IPv6 silent is enabled on
multiple switch interfaces, the interfaces become static DRs. Therefore, multiple DRs exist in
this network segment, and a multicast fault occurs.
Before configuring PIM-IPv6 silent, complete the following tasks:

l Configuring PIM-DM
l Configuring MLD
Data Preparation
To configure PIM-IPv6 silent, you need the following data.
No. Data
1 Number of the switch interface connected to hosts

12.10.2 Configuring PIM-IPv6 Silent

Context
CAUTION
PIM silent is applicable only to the switch interface directly connected to the host network
segment that can be connected to only one PIM switch.
Do as follows on the switch interface connected to the host network segment:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim ipv6 silent
PIM-IPv6 silent is enabled.
After this function is enabled, the attacks from malicious hosts by sending Hello messages are
effectively prevented and the switch is protected.
----End

interface.
Prerequisite
Procedure
----End

12.11 Maintaining PIM-DM

Maintaining IPv6 PIM-DM involves resetting PIM statistics, and monitoring PIM running status.

If you need to re-collect the statistics about IPv6 PIM control messages, you can reset the existent
Context
CAUTION
The statistics of PIM-IPv6 control messages on an interface cannot be restored after you clear
them. So, confirm the action before you use the command.
Procedure
l Run the reset pim ipv6 control-message counters [ interface interface-type interface-
number ] command in the user view to clear statistics of PIM-IPv6 control messages on an
interface.
----End
12.11.2 Monitoring Running Status of PIM-DM

During IPv6 PIM routine maintenance, you can run the display commands in any view to know
the running of PIM.
Context
status of PIM-DM.
Procedure
number ] * command in any view to check the statistics of sent and received PIM-IPv6
control messages.
l Run the display pim ipv6 grafts command in any view to check the unacknowledged PIM-
DM Graft messages.
[ verbose ] command in any view to check information about PIM-IPv6 interfaces.
interface-number | verbose ] * command in any view to check information about PIM-IPv6
neighbors.

l Run the following commands in any view to check the PIM-IPv6 multicast routing table.
----End
12.11.3 Debugging PIM-IPv6

When a fault occurs during the running of IPv6 PIM, run the debugging commands in the user
view and check the contents of sent and received packets for fault location.
Context
CAUTION
Debugging affects the performance of the system. So, after debugging, you need to run the undo
debugging all command to disable the debugging immediately.
When a PIM-IPv6 fault occurs, run the following debugging commands in the user view to
locate the fault.
Procedure
l Run the debugging pim ipv6 all command in the user view to enable all the debugging of
PIM-IPv6.
l Run the debugging pim ipv6 event [ advanced-acl6-number ] command in the user view
to enable the debugging of PIM-IPv6 event.
l Run the debugging pim ipv6 routing-table [ advanced-acl6-number ] command in the
user view to enable the debugging of PIM-IPv6 routing table.
l Run the debugging pim ipv6 neighbor [ basic-acl6-number | [ receive | send ] ] * command
in the user view to enable the debugging of PIM-IPv6 neighbors.
l Run the debugging pim ipv6 assert [ advanced-acl6-number | [ receive | send ] ] *
command in the user view to enable the debugging of PIM-IPv6 Assert.
l Run the debugging pim ipv6 join-prune [ advanced-acl6-number | [ receive | send ] ] *
command in the user view to enable the debugging of PIM-IPv6 Join/Prune.
l Run the debugging pim ipv6 state-refresh [ advanced-acl6-number | [ receive | send ] ]
*command in the user view to enable the debugging of PIM-IPv6 State-Refresh.
----End


Configuration examples are provided to show how to construct a basic IPv6 PIM-DM network.
12.12.1 Example for Configuring the IPv6 PIM-DM Network
On the experiment network shown in Figure 12-1, multicast is deployed. IGP is also deployed
on the network, and unicast routes work normally. The S9300s on the network need to be
configured properly so that user hosts can receive the VoD information in multicast mode.
Figure 12-1 Networking diagram for configuring basic IPv6 PIM-DM functions
Host A Host B
GE2/0/0
3001::1
GE1/0/0
2002::2 SwitchB
GE2/0/0
Source 2002::1
GE1/0/0
2001::1
SwitchA
2001::5
GE3/0/0
2003::1
GE1/0/0
2003::2 SwitchC
GE2/0/0
4001::1
Host C Host D

SwitchA GE1/0/0 VLANIF100 2001::1
GE2/0/0 VLANIF101 2002::1
GE3/0/0 VLANIF102 2003::1
SwitchB GE1/0/0 VLANIF200 2002::2
GE2/0/0 VLANIF201 3001::1
SwitchC GE1/0/0 VLANIF300 2003::2
GE2/0/0 VLANIF301 4001::1

On a small-scale experiment network, PIM-DM is adopted to configure multicast. In this
example, each host network segment is connected to only one S9300, so PIM silent can be used
to prevent the Hello message attack. The configuration roadmap is as follows:
1. Enable multicast on the S9300s.
2. Enable IPv6 PIM-DM on each interface.
3. Enable PIM IPv6 silent and MLD on the router interfaces connected to hosts.
Data Preparation
l Create VLANs and VLANIF interfaces on the S9300s and assign IP addresses to the
VLANIF interfaces.
l Address of the multicast group G: FF0E::1
l Address of the multicast source S: 2001::5
l Version of the MLD protocol running between S9300s and user hosts: MLDv1
Procedure
Step 1 Create VLANs and VLANIF interfaces on the S9300s and assign IP addresses to the VLANIF
Step 2 Enable IPv6 multicast on all S9300s and enable PIM-DM on all interfaces.
# Enable IPv6 multicast on SwitchA and enable PIM-DM on all its interfaces. The configurations
of SwitchB, SwitchC, and SwitchD are similar to the configuration of SwitchA, and are not
provided here.
[SwitchA] interface Vlanif 100
[SwitchA-Vlanif100] pim ipv6 dm
Step 3 On SwitchB, enable PIM silent and MLD on the interface connected to the user host.
[SwitchB] multicast ipv6 routing-enable
[SwitchB] interface Vlanif 201
[SwitchB-Vlanif201] pim ipv6 silent
[SwitchB-Vlanif201] mld enable
[SwitchB-Vlanif201] mld version 1
The configuration of SwitchC is similar to the configuration of SwitchB, and is not provided
here.
# Run the display pim ipv6 interface command, and you can view the configuration and running
status of PIM-IPv6 on interfaces of each S9300. The display of the PIM-IPv6 configuration on
SwitchA is as follows:

<SwitchA> display pim ipv6 interface

Vlanif100 up 0 30 1 FE80::200:AFF:FE01:109
(local)
Vlanif101 up 1 30 1 FE80::A01:109:1(local)
Vlanif102 up 1 30 1 FE80::A01:109:2(local)
# Run the display pim ipv6 neighbor command to check the PIM neighbor relationship between
the S9300s. The display of the PIM-IPv6 neighbor relationship on SwitchA is as follows:
<SwitchA> display pim ipv6 neighbor
Total Number of Neighbors = 2
Neighbor Interface Uptime Expires Dr-Priority BFD-Session
FE80::A01:104:1 Vlanif101 00:04:16 00: 01:29 1 N
FE80::A01:105:1 Vlanif102 00:03:54 00 :01:17 1 N
# Run the display pim ipv6 routing-table command to view the PIM-IPv6 multicast routing
table on an S9300. Assume that Host A joins multicast group G (FF0E::1). SwitchB generates
a (*, G) entry. When multicast source S (2001::5) sends multicast packets to G, a Shortest Path
Tree (SPT) is generated through flooding-prune. The (S, G) entry exists on each S9300 on the
network, and the display is as follows:
<SwitchA> display pim ipv6 routing-table
(2001::5, FF0E::1)
Protocol: pim-dm, Flag: LOC ACT
UpTime: 00:01:20
1: Vlanif101
Protocol: pim-dm, UpTime: 00:01:20, Expires: -
<SwitchB> display pim ipv6 routing-table
(*, FF0E::1)
UpTime: 01:46:23
Upstream neighbor: FE80::A01:109:1
RPF prime neighbor: FE80::A01:109:1
1: Vlanif201
Protocol: mld, UpTime: 01:46:23, Expires: never
(2001::5, FF0E::1)
UpTime: 00:02:19
1: Vlanif201
Protocol: pim-dm, UpTime: 00:02:19, Expires: -
<SwitchC> display pim ipv6 routing-table
(2001::5, FF0E::1)
UpTime: 00:02:19


----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 to 102
#
ipv6
#
#
interface Vlanif100
ipv6 enable
pim ipv6 dm
#
interface Vlanif101
ipv6 enable
pim ipv6 dm
#
interface Vlanif102
ipv6 enable
pim ipv6 dm
#
#
#
#
return

#
sysname SwitchB
#
vlan batch 200 201
#
ipv6
#
#
interface Vlanif200
ipv6 enable
pim ipv6 dm
#
interface Vlanif201
ipv6 enable
pim ipv6 dm
pim ipv6 silent
mld enable

mld version 1
#
#
#
return

#
sysname SwitchC
#
vlan batch 300 301
#
ipv6
#
#
interface Vlanif300
ipv6 enable
pim ipv6 dm
#
interface Vlanif301
ipv6 enable
pim ipv6 dm
pim ipv6 silent
mld enable
mld version 1
#
#
#
return

13 PIM-SM (IPv6) Configuration
About This Chapter
The PIM protocol can be used in an IPv6 network to implement multicast routing and data
forwarding inside an AS. The PIM-SM protocol is a multicast routing protocol of sparse mode.
It is applicable to a large-scale network with sparsely-distributed members.
In an IPv6 PIM-SM network, group members are sparsely distributed and almost all the network
You are allowed to adjust parameters related to neighbor discovery, forwarding, DR, RP, join,
register, and assert. In addition, you can configure various filtering policies and the PIM silent
function to enhance the PIM-SM security. IPv6 PIM-SM supports SSM, PIM GR, and SPT
switchover.
13.3 Configuring Basic PIM-SM (IPv6) Functions
IPv6 PIM-SM on each interface of the multicast device. In this manner, the IPv6 PIM-SM
13.5 Adjusting Control Parameters of a C-RP and a C-BSR
13.6 Adjusting Control Parameters for Maintaining Neighbors
13.7 Adjusting Control Parameters of Source Registering

data in a Register message and sends the message to the RP in unicast mode. The RP then
decapsulates the message, and forwards the multicast data to receivers along the RPT.
A multicast device sends Join messages upstream to require forwarding multicast data and Prune
messages to require stopping the forwarding of multicast data. You can adjust control parameters
for multicast data forwarding as required. If there is no special requirement, adopt default values.
13.9 Configuring Control Parameters for Assert
device.
13.10 Adjusting Control Parameters for the SPT Switchover
To solve this problem, IPv6 PIM-SM allows the RP or the DR at the group member side to
trigger the SPT switchover when the rate of multicast packets is high.
13.11 Configuring PIM GR (IPv6)
In an IPv6 PIM-SM network, PIM GR can be applied to a device with dual main control boards
to ensure normal multicast data forwarding during master-slave switchover.
13.13 Maintaining PIM-SM
Maintaining IPv6 PIM-SM involves resetting PIM statistics, and monitoring PIM running status.
Configuration examples are provided to show how to construct a basic IPv6 PIM-SM network.


In an IPv6 PIM-SM network, group members are sparsely distributed and almost all the network
In the IPv4 multicast applications, the Protocol Independent Multicast (PIM) is used to set
multicast routes between switchs to replicate and forward multicast packets.
In IPv6 multicast applications, switchs run PIM-IPv6. The functions and principles of PIM-IPv6
are similar to the functions of PIM-IPv4.
PIM-IPv6 consists of the following separate protocols:
l PIM-DM: indicates the Protocol Independent Multicast-Dense Mode. PIM-DM is
applicable to a small-scale network with densely-distributed members. The network adopts
the Any-Source Multicast (ASM) model to implement multicast services.
l PIM-SM: indicates the Protocol Independent Multicast-Sparse Mode. PIM-SM is
applicable to a large-scale network with sparsely-distributed members. The network adopts
the ASM and Source-Specific Multicast (SSM) models to implement multicast services.
NOTE
l This chapter describes only the PIM-SM configuration in the IPv6 network. PIM-SM in this chapter
refers to the IPv6 PIM-SM, unless otherwise specified.
l For the configuration of PIM-DM, refer to the chapter PIM-DM (IPv6) Configuration.
l For details of ASM and SSM models, refer to the chapter "IP Multicast Overview" in the Quidway
S9300 Terabit Routing Switch Feature Description - IP Multicast.

You are allowed to adjust parameters related to neighbor discovery, forwarding, DR, RP, join,
register, and assert. In addition, you can configure various filtering policies and the PIM silent
function to enhance the PIM-SM security. IPv6 PIM-SM supports SSM, PIM GR, and SPT
switchover.
Embedded-RP
Based on PIM-SM (IPv4), embedded-Rendezvous Point (Embedded-RP) is added in PIM-SM
(IPv6). The embedded-RP is a method of obtaining an RP. The function of the embedded-RP is
the same as that of the static RP and the dynamic RP.
Static RP
You can specify the static RP on all switchs in the PIM-SM domain. When a dynamic RP exists
in the domain, the dynamic RP is preferred by default, but you can configure the static RP to be
preferred.
Dynamic RP
You can specify a C-RP in a BSR domain, adjust the priority for C-RP election, adjust the lifetime
of the advertisement message on the BSR received from the C-RP, adjust the interval for the C-

RP to advertise advertisement messages, and specify an Access Control List (ACL) to limit the
range of the multicast groups served by the C-RP.
BSR
You can specify a Candidate-BSR (C-BSR) in a BSR domain, adjust the hash mask length used
by the C-RP for C-RP election, adjust the priority for BSR election, and adjust the legal address
range of BSRs.
Controlling a Multicast Source

You can configure the filtering rules based on multicast source addresses to control a multicast
source.
BSR Administrative Domain

To provide precise management, a PIM-SM network is divided into multiple BSR administrative
domains and a Global domain. This can reduce the workload of a single BSR and designate a
group address for users in a specific domain.
Adjusting Control Parameters for Maintaining PIM-SM Neighbors

You can adjust such control parameters of a PIM-SM neighbor relationship as:
l Time period for the neighbor to hold the reachable state
l Whether to accept the Hello messages with Generation IDs
l Maximum delay in triggering the sending of the Hello messages
l Priority for DR election
l DR switching delay
rules.
Adjusting Control Parameters for Source Registering

You can configure the policy to filter Register messages, and set the timeout period for being in
the register suppression state and interval for sending null Register messages by running related
commands.
Adjusting Control Parameters for Multicast Forwarding

You can adjust the control parameters for multicast forwarding, including:
l Interval for sending Join messages
l Time period for the downstream interface to keep the forwarding state
l Time for overriding the prune action
l Filtering Join information in the Join/Prune messages
l Neighbor check function: checks whether the sent or received Join/Prune and Assert
messages are to or from a PIM neighbor. If not, stop sending these messages.


You can configure the period for keeping the Assert state of a switch interface.
Adjusting Control Parameters for SPT Switchover

You can adjust the conditions of the SPT switchover and the interval for checking the forwarding
rate of multicast data.
IPv6 BFD for PIM

The S9300 supports IPv6 BFD for PIM for detecting the status of the link on the shared network
segment within milliseconds and fast responding to the fault on the PIM neighbor.
IPv6 BFD for PIM detects the current DR or Assert winner status on the shared network segment.
When a fault occurs on the interface, BFD immediately instructs the PIM module to trigger a
new DR election or Assert election rather than waits until the neighbor relationship or the Assert
timer times out. This reduces the discontinue period of multicast data transmission and thus
improves the reliability of multicast data transmission.
PIM GR
The S9300 supports the PIM GR function on the switch with double MPUs. PIM GR ensures
normal multicast data forwarding during master-slave switchover of the switch.

On the access layer, the switch interface directly connected to hosts needs to be enabled with
PIM. You can establish a PIM neighbor on the switch interface to process various PIM packets.
The configuration, however, has the security vulnerability. When a host maliciously generates
PIM Hello packets and sends the packets in large quantity, the switch may break down.
To prevent the preceding case, you can set the status of the switch interface to PIM Silent (that
is, PIM pasive state). When the interface is in the PIM silent state, the interface is prohibited
from receiving and forwarding any PIM packet. Then all PIM neighbors and PIM state machines
on the interface are deleted. The interface acts as the static DR and immediately takes effect. At
the same time, MLD on the interface are not affected.
13.3 Configuring Basic PIM-SM (IPv6) Functions

IPv6 PIM-SM on each interface of the multicast device. In this manner, the IPv6 PIM-SM

Before configuring basic IPv6 PIM-SM functions, configure a unicast IPv6 routing protocol.
A PIM-SM network can adopt the ASM and SSM models to provide multicast services for hosts.
The integrated components (including the RP) of the ASM model must be configured in the
network first. The SSM group address range is then adjusted as required.

NOTE
The SSM model needs to be supported by the Multicast Listener Discovery version 2 (MLDv2). If a host
must run MLDv1, configure MLD SSM mapping on the switch interface.
Through MLD, a switch knows the multicast group G that a user wants to join.
l If G is in the SSM group address range and the source S is specified when the user joins G
through MLDv2, the SSM model is used to provide multicast services.
l If G is in the SSM group address range and the switch is configured with the (S, G) SSM
mapping rules, the SSM model is used to provide multicast services.
l If G is not in the SSM group address range, the ASM model is used to provide multicast
services.
In the PIM-SM network, the ASM model supports the following methods used to obtain an RP.
You can select at least one method to obtain an RP.
l Embedded-RP: By default, the embedded-RP is started. The range of groups served by the
embedded-RP is limited.
l Dynamic RP: To obtain a dynamic RP, select several switchs in the PIM-SM domain and
configure them as C-RPs and C-BSRs, and then configure the BSR boundary on the
switch interface on the boundary of the domain. Each switch in the PIM-SM domain can
then automatically obtain the RP.
l Static RP: To obtain a static RP, manually configure the RP on each switch in the PIM-SM
domain. For the large-scale PIM-IPv6 network, configuring a static RP is complicated. To
enhance the robustness and the operation management of the multicast network, the static
RP is usually used as the backup of the BSR-RP.
A multicast group may be in the service range of the embedded-RP, dynamic -RP and static RP
simultaneously. By default, the sequence used by switchs to select an RP is embedded-RP>
dynamic RP > the static RP. If the static RP precedence is configured, the static RP is preferred.
Compared with all groups corresponding to an RP, different multicast groups correspond to
different RPs can reduce the load of a single RP and enhance the robustness of the network.
Before configure basic PIM-SM functions, complete the following task:

l Enable IPv6 function globally
Data Preparation
To configure basic PIM-SM functions, you need the following data.
No. Data
1 The range of groups served by the embedded-RP
2 The IP address of the static RP
3 ACL6 that defines the range of multicast groups served by a static RP
4 The priority of a C-RP

No. Data
5 ACL6 that defines the range of multicast groups served by a C-RP
6 The interval taken by a C-RP to send advertisement messages
7 Timeout period during which a BSR waits to receive the advertisement message from
a C-RP
8 Hash mask length of a C-BSR
9 The priority of a C-BSR
10 SSM group address range

Context
Procedure
Step 1 Run:
system-view

Step 3 Run:
IPv6 multicast routing is enabled in the public network instance.
----End
13.3.3 Enabling Basic PIM-SM (IPv6) Functions

An interface can set up PIM neighbor relationship with other devices after IPv6 PIM-SM is
enabled on it.
Context

Procedure
Step 1 Run:
system-view

Step 2 Run:
The VLANIF interface view is displayed.

Step 3 Run:
pim ipv6 sm
PIM-SM (IPv6) is enabled.

After PIM-SM (IPv6) is enabled on interfaces, switchs set up PIM-IPv6 neighbor relationship
with each other. The switchs can then process protocol packets received from PIM-IPv6
neighbors.
You can run the undo pim ipv6 sm command to disable PIM-SM (IPv6) on an interface.
NOTE
PIM-DM (IPv6) and PIM-SM (IPv6) cannot be enabled on an interface simultaneously. The PIM mode on
all interfaces that belong to the same instance must be the same. When a switch is deployed in a PIM-SM
(IPv6) domain, enable PIM-SM (IPv6) on all non-boundary interfaces.
----End
13.3.4 (Optional) Configuring an Embedded-RP

IPv6 PIM-SM supports the embedded-RP and the range of multicast groups that the embedded-
RP serves set on all devices must be the same.
Context
Do as follows on all switchs in the PIM-SM (IPv6) domain:
NOTE
This configuration is optional. By default, the embedded-RP is enabled. The group address range of the
embedded-RP is FF7x::/12, and the value of x ranges from 0, 3 to F.
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim-ipv6

Step 3 Run:
embedded-rp [ basic-acl6-number | acl6-name acl6-name ]
The group address range of an embedded-RP is specified.

If the address range defined by ACL6 is wider than the default group address range of an
embedded-RP, the embedded-RP is valid for the intersection part of the two address ranges.
NOTE
The group address scope of the embedded-RP on all switchs in the PIM-SM (IPv6) domain must be the
same. You can run the undo embedded-rp command to shut down the embedded-RP.
----End
13.3.5 (Optional) Configuring a Static RP

When only one RP exists in the network, you can manually configure a static RP rather than a
dynamic RP. This can save the bandwidth occupied by message exchange between the C-RP
and the BSR. The configurations about the static RP should be the same on all the devices in an
IPv6 PIM-SM domain.
Context
CAUTION
Configuring a static RP and a BSR-RP in the PIM-SM simultaneously may cause a network
fault. Therefore, confirm the action before you perform this configuration.
If the static RP is not required in this PIM-SM network, this configuration is not necessary.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
static-rp rp-address [ basic-acl6-number | acl6-name acl6-name ] [preferred ]
A static RP is specified.
l rp-address: specifies the static RP address.

l basic-acl6-number | acl6-name acl6-name: specifies the number of the ACL. This basic ACL
defines the scope of groups served by the static RP. When the scopes of multicast groups
that multiple static RP serves overlap, the static RP with the highest IP address acts as the
RP.

l preferred: indicates that the static RP takes precedence. The C-RP is configured in the
network at the same time. After preferred is set, switchs prefer the static RP. Otherwise,
switchs prefer the C-RP.
Multiple static RPs can be configured by using this command repeatedly, but the same ACL
cannot correspond to multiple static RPs. If the ACL is not configured, only one static RP can
be configured.
NOTE
The same static-rp command must be used on all switchs in the PIM-SM domain.
----End
13.3.6 (Optional) Configuring a Dynamic RP

In an IPv6 PIM-SM domain, you can select several PIM devices and configure C-RPs on the
devices. Then, the RP is elected from these C-RPs. The C-BSRs should also be configured and
a BSR is elected from these C-BSRs. The BSR is responsible for collecting and advertising the
C-RP information on the network.
Context
CAUTION
This configuration is applicable only to the dynamic RP. If the dynamic RP is not used in this
network, this configuration is not necessary.
Do as follows on switchs that may become RP in the PIM-SM domain:
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
c-rp ipv6-address [ advertisement-interval interval | group-policy { basic-acl6-
number | acl6-name acl6-name } |holdtime interval | priority priority-value ] *
The C-RP is configured.
l ipv6-address: specifies the IPv6 address of the interface where the C-RP resides. PM-SM
must be enabled on that interface.

l group-policy basic-acl6-number: specifies that the C-RP serves only the multicast group
matching ACL6. basic-acl-number: specifies the number of the basic ACL6. By default, the
C-RP serves all multicast groups.
l priority priority: specifies the priority for electing the C-RP. The greater the value, the lower
the priority. By default, the priority is 192.
NOTE
In the RP election, the C-RP with the highest priority (with the lowest priority value) succeeds. In case
of the same priority, the hash function is calculated, and the C-RP with the greatest hash value succeeds.
In case of the same priority and the same hash value, the C-RP with the highest IP address succeeds.
l holdtime hold-interval: specifies the timeout period during which the BSR waits to receive
the advertisement message from the C-RP. By default, the value is 150s.
l advertisement-interval adv-interval: specifies the interval during which the C-RP sends
advertisement messages. By default, the value is 60s.
Step 4 Run:
c-bsr ipv6-address [ hash-length ]
A C-BSR is configured.
l ipv6-address: specifies the IPv6 address of the interface where the C-BSR resides. The
interface must be configured with PIM-SM.
l hash-length: specifies the length of the hash mask. According to the group address G, C-RP
address, and the value of hash-length, switchs calculate the C-RPs that have the same priority
and want to serve G by operating hash functions, and compare the calculation results. The
C-RP with the greatest calculated value acts as the RP that serves G.
You can use the c-bsr hash-length hash-length command to set the global hash length of the
C-BSRs. The set hash length then applies to all the C-BSRs configured on the switch.

bsm semantic fragmentation
The BSR message fragmentation is enabled.
It is recommended to enable BSR message fragmentation on all devices on the network because
BSR message fragmentation can solve the problem faced by IP fragmentation that all fragments
become unavailable due to loss of fragment information.
----End
13.3.7 (Optional) Configuring the SSM Group Address Range

The default SSM group address range is FF3x::/32. You can manually configure the SSM group
address range. Ensure that the SSM group address ranges configured on all devices in the network
are identical.
Context
NOTE
This configuration is optional. By default, the SSM group address range is FF3x::/32.

Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
ssm-policy { basic-acl6-number | acl6-name acl6-name }
The SSM group address range is configured.
NOTE
Ensure that the SSM group address ranges of all switchs in the network must be identical.
----End

After basic functions of IPv6 PIM-SM are configured, you can check information about the
BSR, RP, PIM interface, PIM neighbor, and PIM routing table through commands.
Procedure
l Run the display pim ipv6 bsr-info command to check information about the BSR in the
PIM-SM (IPv6) domain.
l Run the display pim ipv6 rp-info [ ipv6-group-address ] command to check information
about RPs in the PIM-SM domain.
----End



After basic functions of IPv6 PIM-SM are configured, you can configure the lifetime of a
multicast source and source address-based filtering rules as required.
All the configurations in this section are applicable to the ASM and SSM models.
PIM-IPv6 switchs check the passing multicast data packets. By checking whether the data
packets match the filtering rule, the switchs determine whether to forward the packets. That is,
the switchs in the PIM domain act as filters. The filters help to control data flows, and limit
information obtained by downstream receivers.
NOTE
Switchs under the control of default values can work normally. In the S9300, users can adjust related
parameters according to the actual environment. If there is no special requirement from the actual network,
it is recommended to use default values.
Before adjusting control parameters of a multicast source, complete the following tasks:

l Configuring Basic PIM-SM (IPv6) Functions
Data Preparation
To adjust control parameters of a multicast source, you need the following data.
No. Data
1 Keepalive period of a multicast source
13.4.2 Configuring the Keepalive Period of a Source


Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
The Keepalive period of a source is configured.
When the Keepalive period expires, the (S, G) entry becomes invalid.
----End

After ACL6 rules are configured, a multicast device can filter the received multicast packets
based on source addresses or source/group addresses.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
source-policy { acl6-number | acl6-name acl6-name }
are forwarded.

NOTE
l If acl6-number | acl6-name acl6-name is specified in the source-policy command and ACL rules are
l If acl6-number | acl6-name acl6-name is specified in the source-policy command and no ACL rule is
l The source-policy command does not filter the static (S, G) entries.
----End

Procedure
----End
13.5 Adjusting Control Parameters of a C-RP and a C-BSR


In case that the dynamic RP is used, after basic functions of IPv6 PIM-SM are configured, you
can adjust parameters of C-RPs and C-BSR, configure a BSR boundary, and set valid address
ranges for BSRs and C-RPs.
To enhance the performance of an RP or a BSR, you can adjust control parameters of C-RPs
and C-BSRs by using related commands.
NOTE
parameters according to the actual environment. If there is no special requirement of the actual network,
it is recommended to use default values.

Before adjusting control parameters of a C-RP and a C-BSR, complete the following tasks:
Data Preparation
To adjust control parameters of a C-RP and C-BSR, you need the following data.
No. Data
1 Priority of the C-RP
2 Interval during which the C-RP sending advertisement messages
3 Timeout period during which the BSR waits to receive the advertisement message
from the C-RP
4 Hash mask length of the C-BSR
5 Priority of the C-BSR
6 Interval during which the C-BSR sends Bootstrap messages
7 Period for keeping the Boostrap message received from the BSR
8 ACL6 that defines the legal BSR address range
9 ACL6 that defines the legal C-RP address range
13.5.2 Adjusting Control Parameters of a C-RP

C-RPs periodically send Advertisement messages to a BSR. The Advertisement messages carry
C-RP priorities. You can adjust the C-RP priority, the interval for sending Advertisement
messages, and the holdtime of Advertisement messages on a device configured with the C-RP.
Context
Do as follows on the switch on which the C-RP is configured:
NOTE
Do as follows on the switch that has been configured with a C-RP. This configuration is optional. If there
is no special requirement, default values are recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim-ipv6

Step 3 Run:
c-rp priority priority
The priority of the C-RP is configured.
Step 4 Run:
c-rp advertisement-interval interval
The interval during which the C-RP sends advertisement messages is configured.
Step 5 Run:
c-rp holdtime interval
The period for keeping the advertisement message received from the C-RP is configured.
This period must be longer than the interval during the C-RP sends advertisement messages.
The C-RP periodically sends advertisement messages to the BSR. After receiving the
advertisement messages, the BSR obtains the Holdtime period from the messages. During the
Holdtime period, the advertisement message is valid. When the Holdtime period expires, the C-
RP ages.
----End
13.5.3 Adjusting Control Parameters of a C-BSR

At first, each C-BSR considers itself as a BSR and sends Bootstrap messages to all devices in
the network. You can adjust the hash mask length of the C-BSR carried in a Bootstrap message,
the C-RP priority, the interval for sending Bootstrap messages, and the holdtime of Bootstrap
messages on a device configured with the C-BSR.
Context
Do as follows on the switch on which the C-BSR is configured:
NOTE
Do as follows on the switch that has been configured with a C-BSR. This configuration is optional. If there
is no special requirement, default values are recommended.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
c-bsr hash-length hash-length
The hash mask length of the C-BSR is configured.

Step 4 Run:
c-bsr priority priority
The priority of the C-BSR is configured.
Step 5 Run:
c-bsr interval interval
The interval during which the C-BSR sends Bootstrap messages is configured.
Step 6 Run:
c-bsr holdtime interval
The period for keeping the Bootstrap received from the BSR is configured.
The BSR periodically sends a Bootstrap message to the network. After receiving the Bootstrap
message, the C-BSR keeps the message for a certain period. During the period, the BSR election
stops temporarily. If the Holdtime period expires, a new round of BSR election is triggered
among C-BSRs.
NOTE
Ensure that the period for keeping the Bootstrap message received from the BSR and the interval during
which the BSR sends Bootstrap messages must be the same on all C-BSRs in the PIM-IPv6 domains. The
period for keeping the Bootstrap message received from the BSR must be longer than the interval during
which the BSR sending Bootstrap messages.
----End
13.5.4 Configuring the BSR Service Boundary

A BSR boundary can be configured on an interface. Bootstrap messages cannot pass the BSR
boundary. Multiple BSR boundary interfaces divide the network into different PIM-SM
domains.
Context
Do as follows the switchs that may become BSR boundaries:
NOTE
The BSR boundary is used to divide a PIM-SM (IPv6) domain. switchs outside the BSR boundary do not
take part in the process of multicast forwarding in the PIM-SM (IPv6) domain. This configuration is
optional. By default, all PIM-SM (IPv6) switchs in the network can receive BSR messages.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim ipv6 bsr-boundary

The BSR boundary is configured.
BSR messages cannot pass the BSR boundary.
----End
13.5.5 (Optional) Configuring the Range of Legal BSR addresses

ACL6-based policies can be set on all devices to filter C-BSR addresses. The devices then receive
only the Bootstrap messages with the source addresses being in the valid C-BSR address range.
Thus, BSR spoofing is avoided.
Context
NOTE
This configuration is optional. By default, source addresses of the received BSR packets are not checked,
and all received BSR packets are received.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
bsr-policy { basic-acl6-number | acl6-name acl6-name }
The range of legal BSR addresses is limited.
After receiving an IP packet carrying a Bootstrap message, a switch checks the source address
of the IP packet. If the source address is not in the range of legal BSR addresses, the packet is
discarded. The BSR spoofing is thus avoided.
basic-acl6-number specifies the number of the basic ACL. The ACL defines the filtering policy
for the source addresses of BSR messages.
----End
13.5.6 (Optional) Configuring the Range of Legal C-RP Addresses

ACL6-based policies can be set on all C-BSRs to filter C-RP addresses and addresses of the
groups that the C-RPs serve. The BSR adds C-RP information to the RP-set only when the
addresses are in the set legal address range. Thus, C-RP spoofing is avoided.
Context
Do as follows on all C-BSRs in the PIM-SM domain:

NOTE
This configuration is optional. By default, the C-RP address carried in the received advertisement message
and the address of the group that the C-RP serves are not checked, and all received advertisement messages
are received and added to the RP-set.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
crp-policy { advanced-acl6-number | acl6-name acl6-name }
The range of legal C-RP addresses and the range of groups that C-RPs serve are limited. When
a switch receives an advertisement message, the switch checks the C-RP address and the address
of the group that the C-RP serves in the message. The advertisement message is received and
added to the RP-set only when the C-RP address and the group address are in the legal address
range. The C-RP spoofing is thus avoided.
{ advanced-acl6-number | acl6-name acl6-name }: specifies the number of the advanced ACL.

The ACL defines the filtering policy to limit the range of legal C-RP and the range of groups
that the C-RP serves.
----End

After the control parameters of C-RPs and C-BSRs are adjusted, you can check information
about the BSR and RP and check whether a BSR boundary is configured on the interface through
commands.
Procedure
l Run the display pim ipv6 bsr-info command to check information about BSRs in the PIM-
SM domain.
l Run the display pim ipv6 rp-info [ ipv6-group-address ] command to check information
about RPs in the PIM-SM domain.
----End
13.6 Adjusting Control Parameters for Maintaining

Neighbors


After basic functions of IPv6 PIM-SM are configured, you can adjust related parameters of Hello
messages for controlling neighbor relationships and configure the downstream neighbor tracking
function and the neighbor filtering function.
The configuration in this section is applicable to both the ASM model and the SSM model.
The PIM switchs send Hello messages to each other to establish the neighbor relationship,
negotiate the control parameters, and elect a DR.
The switch can work normally by default. The S9300 allows the users to adjust the parameters
as required.
NOTE
It is recommended to adopt the default value if there is no special requirement.
Before adjusting control parameters for maintaining neighbors, complete the following tasks:

Data Preparation
To adjust control parameters for maintaining neighbors, you need the following data.
No. Data
1 Priority for DR election
2 Timeout period for waiting to receive Hello message from neighbors
5 DR switching delay, that is, the remaining time for the entries to turn invalid after a
DR interface no longer functions as a DR.
13.6.2 Configuring Control Parameters for Maintaining PIM

Neighbors

Context
Do as follows on the PIM-SM (IPv6) switch:
NOTE
The configuration of the control parameters for maintaining PIM neighbors involves the following cases:
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:
The interval for sending Hello messages is configured.

4. Run:
The period for keeping the reachable state of a neighbor is configured.

If the local switch does not receive any Hello message from the neighbor after the
period expires, the local switch considers that the neighbor is unreachable.
1. Run:
system-view

2. Run:

3. Run:
pim ipv6 timer hello interval

4. Run:
pim ipv6 triggered-hello-delay interval

After the maximum delay is set, the conflict caused by multiple PIM-IPv6 switchs
simultaneously sending Hello message is avoided.
5. Run:
pim ipv6 hello-option holdtime interval

The period for keeping the reachable state of a neighbor is configured.

If the local switch does not receive any Hello message from the neighbor after the
period expires, the local switch considers that the neighbor is unreachable.
6. Run:
The Generation ID option is set in received Hello message.

The Hello message without the Generation ID option is refused.
----End
13.6.3 Configuring Control Parameters for Electing a DR

Context
NOTE
The configuration of the control parameters for electing a DR involves the following cases:
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:
hello-option dr-priority priority
The priority for the DR election is configured.

On the shared network segment where all PIM-IPv6 switchs support the DR priority,
the switch interface with highest priority acts as the DR. In the case of the same
priority, the switch interface with the highest IP address acts as the DR. If a minimum
of one PIM-IPv6 switch does not support the DR priority, the switch interface with
the highest IP address acts as the DR.
1. Run:
system-view


2. Run:

3. Run:
pim ipv6 hello-option dr-priority priority-value
The priority for the DR election is configured.

On the shared network segment where all PIM-IPv6 switchs support the DR priority,
the switch interface with highest priority acts as the DR. In the case of the same
priority, the switch interface with the highest IP address acts as the DR. If a minimum
of one PIM-IPv6 switch does not support the DR priority, the switch interface with
the highest IP address acts as the DR.
4. Run:
pim ipv6 timer dr-switch-delay interval
The DR switching delay is configured and the value of the delay is set.
When an interface changes from a DR to a non-DR, the existing routing entries are
valid until the maximum delay expires.
----End
13.6.4 Enabling the Function of Tracking a Downstream Neighbor

Context
Do as follows on the switch running IPv6 PIM-SM:
NOTE

Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:

hello-option neighbor-tracking
The function of tracking downstream neighbors is enabled.
NOTE
The function of tracking downstream neighbors cannot be implemented unless all the switchs
running IPv6 PIM-SM in the shared network segment are enabled with this function.
1. Run:
system-view

2. Run:

3. Run:
pim ipv6 hello-option neighbor-tracking
The function of tracking downstream neighbors is enabled.
NOTE
The function of tracking downstream neighbors cannot be implemented unless all the switchs
running IPv6 PIM-SM in the shared network segment are enabled with this function.
----End

Context
To prevent some switch from being involved in the PIM protocol and prevent this switch from
becoming the DR, filtering PIM neighbors is required.
Do as follows on the switch enabled with IPv6 PIM-SM:
Procedure
Step 1 Run:
system-view
Step 2 Run:


Step 3 Run:
pim ipv6 neighbor-policy { basic-acl6-number | acl6-name acl6-name }

NOTE
When configuring the PIM neighbor filtering function on the interface, you must also configure the
neighbor filtering function correspondingly on the switch that sets up the neighbor relationship with the
interface.
----End

Procedure
----End
13.7 Adjusting Control Parameters of Source Registering

data in a Register message and sends the message to the RP in unicast mode. The RP then

After basic functions of IPv6 PIM-SM are configured, you can configure filtering policies and
the checksumming mode for Register messages and configure PIM-SM Register suppression as
required.
This section describes how to configure the control parameters of the source registering through
In a PIM-SM network, the DR directly connected to the source S encapsulates the received
multicast data in a Register message and unicasts the Register message to the RP. The RP then
After the SPT switchover on the RP is complete, the multicast data reaches the RP along the
source tree in the multicast mode. The RP sends a Register-Stop message to the DR at the source
side. The DR then stops sending Register messages and enters the suppressed state. In the register

suppression period, the DR periodically sends a Probe message (null Register message) to notify
the RP that the multicast source is still in the active state. After the register suppression expires,
the DR resends the Register message carrying a multicast data packet.
NOTE
parameters according to the specific network environment. If there is no special requirement, default values
are recommended.
Before adjusting control parameters of source registering, complete the following tasks:
Data Preparation
To adjust control parameters of source registering, you need the following data.
No. Data
1 ACL6 rules used by the RP to filter Register messages
2 Timeout period for keeping the suppressed state of the source registering
3 Interval for sending null Register messages to the RP
13.7.2 Configuring Rules for Filtering PIM-SM (IPv6) Register

Messages
You can configure policies on filtering Register messages on all the routers that may become
RPs. By default, the checksum is calculated based on the entire Register message. You can
configure the device to calculate the checksum based on only the header of a Register message.
Context
Do as follows on switchs that may become RPs:
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim-ipv6

Step 3 Run:
register-policy { advanced-acl6-number | acl6-name acl6-name }

The rules for filtering Register messages are set.

The RP accepts or rejects to a Register message according to the rules.
----End
13.7.3 Configuring PIM-SM (IPv6) Registering Suppression

You can set the timeout period for keeping the register suppression state and the interval for
sending null Register messages on all the devices that may become DRs at the multicast source
side.
Context
Do as follows on the switch that may become the DR at the source side:
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim-ipv6

Step 3 Run:
register-suppression-timeout interval
The timeout period for keeping the suppressed state of the registering is set.
Step 4 Run:
probe-interval interval
The interval for sending null Register messages is set.
----End

After control parameters for source registering are adjusted, you can run the corresponding
command to check information about the PIM interface.
Procedure
----End

A multicast device sends Join messages upstream to require forwarding multicast data and Prune
messages to require stopping the forwarding of multicast data. You can adjust control parameters
for multicast data forwarding as required. If there is no special requirement, adopt default values.


After basic functions of IPv6 PIM-DM are configured, you can adjust control parameters used
to maintain the forwarding relationship, and configure the Join information filtering and
neighbor filtering functions to enhance security as required.
Unless otherwise specified, the configurations in this section are applicable to both the ASM
model and the SSM model.
When the first member of a group appears on a switch, the switch sends a Join message through
the upstream interface to require the upstream switch to forward packets to this network segment.
When the last member of a group on the switch leaves its group, the switch sends the Prune
message through the upstream interface to request the upstream switch to perform the prune
action. After receiving the Prune message, the upstream interface stops forwarding packets to
this network segment. If other downstream switchs exist in this network segment, they must
send the Join message to override the prune action.
In the ASM model, the switchs periodically send Join messages to the RP in case the RPT branch
is deleted because of timeout.
NOTE
are recommended.
Before adjusting control parameters for forwarding, complete the following tasks:

Data Preparation
To adjust control parameters for forwarding, you need the following data.
No. Data
2 Period of overriding the Prune action
4 Interval for sending Join messages
5 Number or name of the ACL used to filter join information
6 Whether to perform neighbor check on the received or sent Join/Prune messages and
Assert messages

13.8.2 Configuring Control Parameters for Keeping the Forwarding

Relationship
The control parameters of multicast data forwarding can be set either globally or on an interface.
The parameters specify the interval for sending Join/Prune messages and the period for a
downstream interface to keep the Join/Prune state.
Context
NOTE
The configuration of the control parameters for maintaining the forwarding relationship involves the
following cases:
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:
timer join-prune interval

4. Run:
The value of the Holdtime field in the sent Join/Prune message is set.
The Holdtime period is the period for keeping the Forwarding/Prune state of the
downstream interface.
1. Run:
system-view

2. Run:

3. Run:
pim ipv6 timer join-prune interval

4. Run:
pim ipv6 holdtime join-prune interval
The value of the Holdtime field in the sent Join/Prune message is set.
The Holdtime period is the period for keeping the Forwarding/Prune state of the
downstream interface.
5. Run:
The Generation ID option is set in received Hello message.

The Hello message without the Generation ID option is refused.
The change of the Generation ID in the Hello message received from the upstream
neighbor indicates that the upstream neighbor is lost or the status of the upstream
neighbor has changed.
----End
13.8.3 Configuring Control Parameters for Prune

The prune control parameters can be set either globally or on an interface. The parameters specify
the delay for transmitting messages in a LAN and the interval for overriding the Prune action.
Context
The Hello message carries lan-delay ( which indicates the delay for transmitting prune message )
and override-interval ( which indicates the interval for overriding a prune ). The relationship
between lan-delay, override-interval, and PPT is that lan-delay + override-interval = PPT. Prune-
Pending Timer (PPT) indicates the delay from the time when a switch receives the Prune message
from the downstream interface to the time when the switch performs the prune action to suppress
the forwarding of the downstream interface. If the switch receives a Join message from a
downstream switch within the PPT, the switch does not perform the prune action.
NOTE
The configuration of the control parameters of prune involves the following cases:
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:

The delay of transmitting messages in a LAN is set.

4. Run:
The period for overriding the prune action is set.

When a switch receives a Prune message through an upstream interface, it indicates
that another downstream switch exists in the LAN. If the switch still needs to receive
the multicast data, the switch must send a Join message to the upstream within the
override-interval.
1. Run:
system-view

2. Run:

3. Run:
pim ipv6 hello-option lan-delay interval

4. Run:
pim ipv6 hello-option override-interval interval
The period for overriding the prune action is set.

----End
13.8.4 Configuring Join Information Filtering

information. You can configure the interface to filter join information based on ACL6 rules. The
device then creates PIM entries for only the join information matching ACL6 rules.
Context
information. You can configure the switch to filter join information based on ACL6 rules. The
switch then creates PIM entries for only the join information matching ACL6 rules, which can
prevent illegal users from accessing the group.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
pim ipv6 join-policy { asm { basic-acl6-number | acl6-name acl6-name } | ssm
{ advanced-acl6-number | acl6-name acl6-name } }
Join information filtering is configured.
----End
13.8.5 Configuring Neighbor Check

If PIM neighbor check is enabled, a device checks whether the Join/Prune and Assert messages
are sent to or received from a PIM neighbor. If not, the device drops the messages.
Context
By default, checking whether the Join/Prune message and Assert messages are sent to or received
from a PIM neighbor is not enabled.
If PIM neighbor checking is required, it is recommended to configure the neighbor checking

function on the devices connected with user devices rather than on the internal devices of the
network. Then, the switch checks whether the Join/Prune and Assert messages are sent to or
received from a PIM neighbor. If not, the switch drops the messages.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
The IPv6 PIM view is displayed.
Step 3 Run:
neighbor-check { receive | send }
The neighbor check function is configured.
You can specify both receive and send to enable the IPv6 PIM neighbor check function for both
the received and sent Join/Prune messages and Assert messages.
----End

After control parameters for multicast data forwarding are adjusted, you can check information
about the PIM interface and the PIM routing table and statistics about PIM control messages
through commands.

Procedure
----End
13.9 Configuring Control Parameters for Assert

device.

After basic functions of IPv6 PIM-SM are configured, you can set the period for holding the
Assert state as required.
The configurations in this section are applicable to both the ASM model and the SSM model.
When a PIM-SM switch receives multicast data through the downstream interface, this indicates
that other upstream switchs exist in this network segment. The switch sends an Assert message
through the downstream interface to take part in the assert election.
NOTE
switchs under the control of default values can work normally. In the S9300, you can adjust related
are recommended.
Before adjusting control parameters for assert, complete the following tasks:


Data Preparation
To adjust control parameters for asset, you need the following data.
No. Data
1 The period for keeping the Assert state

The device that fails the election prevents its downstream interface from forwarding multicast
data during the Assert state. After the holdtime of the Assert state expires, the downstream
interface can forward multicast data.
Context
Do as follows on all switchs in the PIM-SM (IPv6) domain:
NOTE
The configuration of control parameters for Assert involves the following cases:
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:
The period for keeping the Assert state is configured.
forwarding multicast data in this period. After the period expires, the switch restores
the forwarding of the downstream interface.
1. Run:
system-view

2. Run:


3. Run:
pim ipv6 holdtime assert interval

forwarding multicast data in this period. After the period expires, the switch restores
the forwarding of the downstream interface.
----End

commands.
Procedure
----End
13.10 Adjusting Control Parameters for the SPT Switchover

To solve this problem, IPv6 PIM-SM allows the RP or the DR at the group member side to
trigger the SPT switchover when the rate of multicast packets is high.

After basic functions of IPv6 PIM-SM are configured, you can adjust control parameters for
SPT switchover as required.
This section describes how to configure the control parameters of the SPT switchover through

In PIM-SM forwarding, each multicast group corresponds to an RPT. At first, all multicast
sources encapsulate data in Register messages, and send the messages to the RP in the unicast
mode. The RP decapsulates the messages and forwards the data along the RPT.
Forwarding multicast data by using the RPT has the following disadvantages:
l The DR at the source side and the RP need to encapsulate and decapsulate packets.
l The forwarding path may not be the shortest path from the source to receivers.
l Heavy data traffic increases the load of the RP, and may cause a fault.
The solution to the preceding disadvantages is that:
l SPT switchover triggered by the RP: The RP sends a Join message to the source, and
establishes a multicast route along the shortest path from the DR at the source side to the
RP. The subsequent packets are forwarded along the path.
l SPT switchover triggered by the DR at the receiver side: The DR at the receiver side checks
the forwarding rate of multicast data. If the DR finds that the rate exceeds the threshold,
the DR triggers the SPT switchover immediately. The DR sends a Join message to the
source, and establishes a multicast route along the shortest path from the DR at the source
side to the DR at the receiver side. The subsequent packets are forwarded along the path.
NOTE
switchs under the control of default values can work normally. In the S9300, users can adjust related
are recommended.
Before adjusting control parameters for the SPT switchover, complete the following tasks:

Data Preparation
To adjust control parameters for the SPT switchover, you need the following data.
No. Data
1 Forwarding rate threshold that the DR at the receiver side switches packets from the
RPT to the SPT
2 Group filtering policy and sequence policy for the RPT-to-SPT switchover
3 Interval for checking the forwarding rate threshold of multicast data before RPT-to-
SPT switchover
13.10.2 (Optional) Adjusting Conditions of the SPT Switchover

You can configure SPT switchover conditions on the DR at the group member side. The DR
then checks the forwarding rate of multicast data. If finding that the rate exceeds the threshold,
the DR triggers the SPT switchover immediately.

Context
Do as follows on the switch that may become the DR at the receiver side:
NOTE
This configuration is optional. By default, the RP and the DR at the receiver side immediately perform the
SPT switchover after receiving the first multicast data packet.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
spt-switch-threshold { traffic-rate | infinity } [ group-policy { basic-acl6-
number | acl6-name acl6-name } [ order order-value ] ]
Conditions of the SPT switchover are adjusted.
l traffic-rate: specifies the rate threshold of SPT switchover.

l infinity: indicates that the SPT switchover is not triggered.
l group-policy { basic-acl6-number | acl6-name acl6-name } [ order order-value ]: specifies
the range of the multicast groups that use the threshold. By default, the threshold is applicable
to all multicast groups.
----End
13.10.3 (Optional) Configuring the Interval for Checking the

Forwarding Rate of Multicast Data
After conditions for the SPT switchover are configured, you can set the interval for checking
the forwarding rate of multicast data.
Context
Do as follows on the switch that may become the DR at the receiver side:
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6

Step 3 Run:
timer spt-switch interval
The interval for checking the forwarding rate of multicast data is set.
By default, the DR at the receiver side performs SPT switchover after receiving the first multicast
data packet.
NOTE
Before configuring the timer spt-switch command, run the spt-switch-threshold command to set the
threshold of the rate that will trigger SPT switchover. Otherwise, timer spt-switch does not take effect.
----End

After the control parameters for SPT switchover are adjusted, you can run commands to check
Procedure
----End
13.11 Configuring PIM GR (IPv6)

In an IPv6 PIM-SM network, PIM GR can be applied to a device with dual main control boards
to ensure normal multicast data forwarding during master-slave switchover.

After basic functions of IPv6 PIM-SM are configured, you can configure PIM GR to improve
PIM network reliability.
In some multicast applications, the switch may need to perform active/standby switchover. After
active/standby switchover, the new active main control board deletes the forwarding entries on
the interface board and re-learns the PIM routing table and multicast routing table. During this
process, multicast traffic is interrupted.
In the PIM-SM/SSM network, PIM Graceful Restart (GR) can be applied to the switch with dual
main control boards to ensure normal multicast traffic forwarding during active/standby
switchover.
The active main control board of the switch backs up PIM routing entries and Join/Prune
information to be sent upstream to the standby main control board. The interface board keeps
forwarding entries. Therefore, after active/standby switchover, the switch can actively and fast
send Join messages upstream to maintain the Join state of the upstream. Then, the PIM protocol
sends Hello messages carrying new Generation ID to all switchs enabled with PIM-SM. When
the downstream switch finds that the Generation ID of its neighbor changes, it sends a Join/

Prune message to the neighbor for re-creating routing entries, thereby ensuring non-stop
forwarding of multicast data on the forwarding plane.
If a dynamic RP is used on the network, after receiving a Hello message with the Generation ID
being changed, the DR or candidate DR unicasts a BSM message to the switch performing active/
standby switchover and the switch learns and restores RP information based on the received
BSM message. If the switch has not leant any RP information from the BSM messages, it obtains
the RP information from the Join/Prune message received from the downstream router and re-
creates multicast routing table.
NOTE
PIM GR is applicable to PIM-SM/SSM networks.
Before configuring PIM GR, complete the following task:
l Configuring a unicast routing protocol and enabling unicast GR

Data Preparation
To enable PIM GR, you need the following data.
No. Data
1 Unicast GR period
2 PIM-IPv6 GR period
13.11.2 Configuring PIM GR (IPv6)

After PIM GR is enabled on a device, you can set the PIM GR period as required.
Context
Do as follows on the switch enabled with PIM SM (IPv6).
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
The IPv6 PIM view is displayed.
Step 3 Run:
graceful-restart

PIM GR is enabled.
graceful-restart period period
The PIM GR period is set.

By default, the PIM GR period is 120 seconds.
----End

After PIM GR is configured, you can run the command to check whether the PIM routing table
is the same as that before master-slave switchover.
Procedure
Step 1 Run the following commands to check IPv6 PIM routing table.
l display pim ipv6 routing-table [ ipv6-source-address [ mask mask-length ] | ipv6-group-
address [ mask mask-length ] | flags { act | del | exprune | ext | loc | niif | nonbr | none |
rpt | sg_rcvr | sgjoin | spt | swt | wc | upchg } | fsm | incoming-interface { interface-type
interface-number | register } | mode { dm | sm | ssm } | outgoing-interface { exclude |
include | match } { interface-type interface-number | none | register } ] * [ outgoing-
interface-number [ number ] ]
l display pim ipv6 routing-table brief [ ipv6-source-address [ mask mask-length ] | ipv6-
group-address [ mask mask-length ] | incoming-interface { interface-type interface-
number | register } ] *
----End


After basic functions of IPv6 PIM-SM and MLD are configured, you can configure the PIM
silent function on the interface connected with the user host. This interface should be enabled
with IPv6 PIM-SM and MLD first.
At the access layer, the switch interface directly connected to hosts needs to be enabled with
PIM-IPv6. You can establish the PIM-IPv6 neighbor relationship on the switch interface to
process various PIM-IPv6 packets. The configuration, however, has the security vulnerability.
When a host maliciously generates PIM-IPv6 Hello packets and sends the packets in large
quantity, the switch may break down.
To avoid the preceding case, you can set the status of the switch interface to PIM-IPv6 silent.
When the interface is in the PIM-IPv6 silent state, the interface is prohibited from receiving and

forwarding any PIM-IPv6 packet. All PIM-IPv6 neighbors and PIM-IPv6 state machines on the
interface are deleted. The interface acts as the static DR and immediately takes effect. At the
same time, MLD on the interface is not affected.
To enable PIM-IPv6 silent, the network environment must meet the following conditions:
l The network supports IPv4 and IPv6.
l The PIM-IPv6 silent is applicable only to the switch interface directly connected to the host
network segment that is connected only to this switch.
CAUTION
If PIM-IPv6 silent is enabled on the interface connected to a switch, the PIM-IPv6 neighbor
If the host network segment is connected to multiple switchs and PIM-IPv6 silent is enabled on
multiple switch interfaces, the interface become static DRs. Therefore, multiple DRs exist in
this network segment, and a multicast fault occurs.
Before configuring PIM-IPv6 silent, complete the following tasks:
l Configuring PIM-SM
l Configuring MLD
Data Preparation
To configure PIM-IPv6 silent, you need the following data.
No. Data
1 The number of the switch interface connected to hosts
13.12.2 Configuring PIM-IPv6 Silent

this interface automatically becomes the DR. MLD on the interface is not affected.
Context
CAUTION
PIM-IPv6 silent is applicable only to the switch interface connected to the host network segment
that can be connected to only one PIM-IPv6 switch.

Do as follows on the switch interface connected to the host network segment:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
pim ipv6 silent
PIM-IPv6 silent is enabled.

After this function is enabled, the Hello packet attack of malicious hosts is effectively prevented
and the connected switchs are protected.
----End

interface.
Prerequisite
Procedure
----End
13.13 Maintaining PIM-SM

Maintaining IPv6 PIM-SM involves resetting PIM statistics, and monitoring PIM running status.
13.13.1 Clearing Statistics of PIM-IPv6 Control Messages

If you need to re-collect the statistics about IPv6 PIM control messages, you can reset the existent

Context
CAUTION
The statistics of PIM-IPv6 control messages on an interface cannot be restored after you clear
it. Therefore, confirm the action before you use the command.
Procedure
l Run the reset pim ipv6 control-message counters [ interface interface-type interface-
number ] command in the user view to clear statistics of PIM-IPv6 control messages on an
interface.
----End
13.13.2 Clearing the PIM Status of the Specified Downstream

Interfaces of PIM Entries
You can clear the PIM Join/Prune state and Assert state on the specified downstream interface
of an IPv6 PIM entry. MLD status and static multicast groups on this interface are not affected.
Context
CAUTION
Clearing PIM status of the downstream interfaces may trigger the sending of corresponding Join/
Prune messages, which affects multicast services.
Using the following command can clear join information about illegal users, and clear the PIM
status of the specified interface in a specified entry, such as PIM Join/Prune status and Assert
status.
The command cannot be used to clear the MLD or static group join status on a specified interface.
Procedure
Step 1 After confirming that PIM status of the specified downstream interfaces of the specified PIM
entry need to be cleared, run the reset pim ipv6 routing-table group ipv6-group-address
mask ipv6-group-mask-length source ipv6-source-address interface interface-type interface-
number command in the user view.
----End
13.13.3 Monitoring the Running Status of PIM-SM

During IPv6 PIM routine maintenance, you can run the display commands in any view to know
the running of PIM.

Context
status of PIM-SM.
Procedure
number ] * command in any view to check the number of sent and received PIM-IPv6
control messages.
l Run the display pim ipv6 bsr-info command in any view to check information about the
BSR.
l Run the display pim ipv6 claimed-route [ ipv6-source-address ] command in any view
to check unicast routing information used by (S, G) and (*, G) entries in the PIM-SM routing
table.
l Run the display pim ipv6 rp-info [ ipv6-group-address ] command in any view to check
information about the RP to which the multicast group corresponds.
l Run the display pim ipv6 grafts command in any view to check the unacknowledged PIM-
IPv6 Graft messages.
[ verbose ] command in any view to check information about PIM-IPv6 interfaces.
interface-number | verbose ] * command in any view to check information about PIM-IPv6
neighbors.
l Run the following commands in any view to check the PIM-IPv6 multicast routing table.
----End
13.13.4 Debugging PIM-IPv6

When a fault occurs during the running of IPv6 PIM, run the debugging commands in the user
view and check the contents of sent and received packets for fault location.
Context
CAUTION

When a PIM-IPv6 fault occurs, run the following debugging commands in the user view to
locate the fault.
Procedure
l Run the debugging pim ipv6 all command in the user view to enable all the PIM-IPv6
debugging.
l Run the debugging pim ipv6 event [ advanced-acl6-number ] in the user view to enable
the debugging of PIM-IPv6 events.
l Run the debugging pim ipv6 routing-table [ advanced-acl6-number ] command in the
user view to enable the debugging of PIM-IPv6 routing table.
l Run the debugging pim ipv6 neighbor [ basic-acl6-number | [ receive | send ] ] * command
in the user view to enable the debugging of PIM-IPv6 neighbors.
l Run the debugging pim ipv6 assert [ advanced-acl6-number | [ receive | send ] ] *
command in the user view to enable the debugging of PIM-IPv6 Assert.
l Run the debugging pim ipv6 join-prune [ advanced-acl6-number | [ receive | send ] ] *
command in the user view to enable the debugging of PIM-IPv6 Join/Prune.
l Run the debugging pim ipv6 rp [ receive | send ] command in the user view to enable the
debugging of PIM-IPv6 RP.
l Run the debugging pim ipv6 register [ advanced-acl6-number ] command in the user view
to enable the debugging of PIM-IPv6 Register.
----End

Configuration examples are provided to show how to construct a basic IPv6 PIM-SM network.
13.14.1 Example for Configuring the IPv6 PIM-SM Network
As shown in Figure 13-1, multicast is deployed on the network of an Internet service provider
(ISP). The network is deployed with IGP and is connected to the Internet. The unicast routing
routes work normally. The S9300s on the network need to be configured properly so that user
hosts can receive the VoD information in multicast mode.

Figure 13-1 Networking diagram for configuring basic IPv6 PIM-DM functions
SwitchB HostA
GE2/0/0
3001::1
GE1/0/0
2002::2
GE3/0/0 HostB
2004::1
GE2/0/0
2002::1 GE2/0/0
SwitchA GE3/0/0 2004::2
2003::1 SwitchD
GE1/0/0 GE1/0/0
2001::1 GE4/0/0 2003::2 GE3/0/0
Source 2006::1
2001::5 2005::1
GE1/0/0
2005::2 HostC
Internet
GE2/0/0
4001::2 HostD
SwitchC

SwitchA GE1/0/0 VLANIF100 2001::1
GE2/0/0 VLANIF101 2002::1
GE3/0/0 VLANIF102 2003::1
GE4/0/0 VLANIF103 2006::1
SwitchB GE1/0/0 VLANIF200 2002::2
GE2/0/0 VLANIF201 3001::1
GE3/0/0 VLANIF202 2004::1
SwitchC GE1/0/0 VLANIF300 2005::2
GE2/0/0 VLANIF301 4001::2
SwitchD GE1/0/0 VLANIF400 2003::2
GE2/0/0 VLANIF401 2004::2
GE3/0/0 VLANIF402 2005::1
The ISP network is connected to the Internet. Therefore, to facilitate service expansion, IPv6
PIM-SM protocol is used to configure the multicast function and ASM and SSM models are
adopted to provide multicast services. In this example, each host network segment is connected
to only one S9300, so PIM silent can be used to prevent the Hello message attack. The
configuration roadmap is as follows:
1. Create VLANs and VLAN interfaces on the S9300s and assign IPv6 addresses to the VLAN
2. Enable multicast on the S9300s.

3. Enable IPv6 PIM-SM on all router interfaces.

4. Configure the C-BSR and C-RP on SwitchD.
5. Configure the BSR boundary on the interface connecting SwitchA to the Internet.
6. Configure the SSM address range on each S9300.
7. Enable PIM IPv6 silent and MLD on the interfaces connected to hosts.
Data Preparation
l MLD version running on the interfaces of S9300s connected to user hosts: MLDv2
l Global unicast IPv6 address of the C-BSR and C-RP: 2004::2
l SSM group address range: FF3E::1/64
Procedure
Step 1 Create VLANs and VLAN interfaces on the S9300s and assign IPv6 addresses to the VLAN
Step 2 Enable IPv6 multicast on all S9300s and enable IPv6 PIM-SM on all interfaces.
# Enable IPv6 multicast on SwitchA and enable IPv6 PIM-SM on all its interfaces.
The configurations of SwitchB, SwitchC, and SwitchD are similar to the configuration of
SwitchA, and are not provided here.
# Run the display pim ipv6 interface command to check the PIM configuration and the running
information on each interface.
Step 3 Configure the C-BSR and C-RP.
# Configure the C-RP on SwitchD and specify the range of groups that the C-RP serves.
[SwitchD] acl ipv6 number 2001
[SwitchD-acl6-basic-2001] rule permit source ff3e::1 64
[SwitchD-acl6-basic-2001] quit
[SwitchD] pim-ipv6
[SwitchD-pim6] c-rp 2004::2 group-policy 2001
# Configure the C-BSR on SwitchD.

[SwitchD-pim6] c-bsr 2004::2
[SwitchD-pim6] quit
# Run the display pim ipv6 bsr-info command on the S9300s to check information about the
BSR election. Take information about the BSR on SwitchB and SwitchD as an example. On
SwitchD, information about the C-BSR is displayed.

<SwitchB> display pim ipv6 bsr-info

Elected BSR Address: 2004::2
Priority: 0
State: Accept Preferred
Uptime: 00:04:22
Expires: 00:01:46
C-RP Count: 1
<SwitchD> display pim ipv6 bsr-info
Elected BSR Address: 2004::2
Priority: 0
State: Elected
Uptime: 00:01:10
Next BSR message scheduled at: 00:00:48
C-RP Count: 1
Candidate AdminScoped BSR Count: 0
Candidate BSR Address: 2004::2
Priority: 0
State: Elected
Wait to be BSR: 0
# Run the display pim ipv6 rp-info command to view the RP information on each S9300. Take
the RP information on SwitchB as an example.
<SwitchB> display pim ipv6 rp-info
PIM-SM BSR RP information:
Group/MaskLen: FF3E::1/64
RP: 2004::2
Priority: 192
Uptime: 00:05:19
Expires: 00:02:11
Step 4 Configure the BSR boundary on the interface connecting SwitchA to the Internet.
[SwitchA-Vlanif103] pim ipv6 bsr-boundary
Step 5 Configure the SSM group address range on all S9300s on the network.
# Configure the PIM-IPv6 SSM group address range on SwitchA to FF3E::1/64.
[SwitchA] acl ipv6 2000
[SwitchA-acl6-basic-2000] rule permit source FF3E::1 64
[SwitchA-acl6-basic-2000] quit
[SwitchA] pim-ipv6
[SwitchA-pim6] ssm-policy 2000
[SwitchA-pim6] quit
The configurations of SwitchB, SwitchC, and SwitchD are similar to the configuration of
SwitchA, and are not provided here.
Step 6 Enable PIM silent and MLD on the interfaces connected to hosts.
# On SwitchB, enable PIM silent and MLD on the interface connected to hosts.
[SwitchB] interface Vlanif 201
[SwitchB-Vlanif201] pim ipv6 silent
[SwitchB-Vlanif201] mld enable
The configuration on SwitchC is similar to the configuration on SwitchB, and is not provided
here.

# Run the display pim ipv6 interface command to check the PIM configuration and the running
information on each interface. Take the RP information on SwitchB as an example.
<SwitchB> display pim ipv6 interface
Vlanif200 up 1 30 1 FE80::A01:10E:1 (local)
Vlanif201 up 0 30 1 FE80::200:AFF:FE01:10E
(local)
Vlanif203 up 1 30 1 FE80::9D62:0:FDC5:2
# The multicast source S 2001::5 simultaneously sends packets to group FF3E::1 (in the SSM
group address range) and FF0E::1 (not in the SSM group address range). Host A and Host C
need to receive information from group FF0E::1. Host B needs to receive information sent from
S 2001::5 to group FF3E::1.
<SwitchA> display pim ipv6 routing-table
(2001::5, FF0E::1)
RP: 2004::2
Protocol: pim-sm, Flag: SPT LOC ACT
UpTime: 00:02:15
1: Register
2: Vlanif101
3: Vlanif102
(2001::5, FF3E::1)
Protocol: pim-ssm, Flag: LOC SG_RCVR
UpTime: 00:00:11
1: Vlanif101
Protocol: pim-ssm, UpTime: 00:00:11, Expires: 00:03:19
(*, FF0E::1)
RP: 2004::2
UpTime: 00:14:44
Upstream neighbor: FE80::9D62:0:FDC5:2
RPF prime neighbor: FE80::9D62:0:FDC5:2
1: Vlanif201
Protocol: mld, UpTime: 00:14:44, Expires: -
(2001::5, FF0E::1)
RP: 2004::2
UpTime: 00:2:42
Upstream neighbor: FE80::A01:10C:1
RPF prime neighbor: FE80::A01:10C:1


1: Vlanif201
(2001::5, FF3E::1)
Protocol: pim-ssm, Flag: SG_RCVR
UpTime: 00:08:02
Upstream neighbor: FE80::A01:10C:1
RPF prime neighbor: FE80::A01:10C:1
1: Vlanif201
Protocol: pim-ssm, UpTime: 00:08:02, Expires: -
(*, FF0E::1)
RP: 2004::2
UpTime: 00:14:44
Upstream neighbor: FE80::7493:FE25:1
RPF prime neighbor: FE80::7493:FE25:1
1: Vlanif301
(2001::5, FF0E::1)
RP: 2004::2
UpTime: 00:2:42
Upstream neighbor: FE80::7493:FE25:1
RPF prime neighbor: FE80::7493:FE25:1
1: Vlanif301
<SwitchD> display pim ipv6 routing-table
(*, FF0E::1)
RP: 2004::2 (local)
UpTime: 00:16:56
1: Vlanif401
2: Vlanif402
(2001::5, FF0E::1)
RP: 2004::2 (local)
Protocol: pim-sm, Flag: SWT ACT
UpTime: 00:02:54
Upstream neighbor: FE81::659:10C:3
RPF prime neighbor: FE81::659:10C:3
1: Vlanif402
----End

Configuration Files
#
sysname SwitchA
#
#
ipv6
#
#
rule 0 permit source FF3E::1/64
#
interface Vlanif100
ipv6 enable
pim ipv6 sm
#
interface Vlanif101
ipv6 enable
pim ipv6 sm
#
interface Vlanif102
ipv6 enable
pim ipv6 sm
#
interface Vlanif103
ipv6 enable
pim ipv6 sm
pim ipv6 bsr-boundary
#
interface GigabieEthernet1/0/0
#
#
#
#
pim-ipv6
ssm-policy 2000
#
return

#
sysname SwitchB
#
#
ipv6
#
#

#
interface Vlanif200
ipv6 enable
pim ipv6 sm
#
interface Vlanif201
ipv6 enable
pim ipv6 sm
pim ipv6 silent
mld enable
#
interface Vlanif202
ipv6 enable
pim ipv6 sm
#
#
#
#
pim-ipv6
ssm-policy 2000
#
return
#
sysname SwitchC
#
vlan batch 300 301
#
ipv6
#
#
#
interface Vlanif300
ipv6 enable
pim ipv6 sm
#
interface Vlanif301
ipv6 enable
pim ipv6 sm
pim ipv6 silent
mld enable
#
#
#
pim-ipv6
ssm-policy 2000

#
return
#
sysname SwitchD
#
#
ipv6
#
#
#
#
interface Vlanif400
ipv6 enable
pim ipv6 sm
#
interface Vlanif401
ipv6 enable
pim ipv6 sm
#
interface Vlanif402
ipv6 enable
pim ipv6 sm
#
pim-ipv6
c-bsr 2004::2
c-rp 2004::2 group-policy 2001
#
#
#
#
pim-ipv6
ssm-policy 2000
#
13.14.2 Example for Configuring PIM GR (IPv6)
In a multicast application, if the active/standby switchover occurs on the device, the new master
MPU deletes multicast forwarding entries from the LPUs and relearns PIM routes and multicast
forwarding entries. During this process, multicast traffic is interrupted.
The PIM GR function on an IPTV network protects the core devices and edge devices. When
an active/standby switchover occurs, the PIM GR function ensures that the multicast data is
forwarded normally. This improves the fault tolerance capability of the devices on the IPTV
network.

As shown in Figure 13-2, the multicast service is deployed on the network. When SwitchC
enabled with the PIM GR function forwards multicast data to the receiver, the master MPU backs
up the PIM routes and Join/Prune messages to be sent to the upstream to the slave MPU. When
the active/standby switchover occurs on SwitchC, the LPUs maintain the existing forwarding
entries to ensure the uninterrupted forwarding of multicast data. The receiver can always receive
multicast data from the source during the active/standby switchover.
Figure 13-2 Networking diagram of PIM GR
Ethernet
Leaf networks
SwitchA
GE1/0/0 GE2/0/0
Source
GE2/0/0 GE1/0/0 GE1/0/0 GE2/0/0
SwitchB SwitchC
Receiver
PIM-SM HostA
Ethernet
Device Interface IPv6 address

SwitchA GE1/0/0,VLANIF 10 2001:2::1/64
GE2/0/0,VLANIF 20 2001:1::2/64
SwitchB GE1/0/0,VLANIF 30 2001:2::2/64
GE2/0/0,VLANIF 40 2001:5::1/64
SwitchC GE1/0/0,VLANIF 50 2001:5::2/64
GE2/0/0,VLANIF 60 2001:6::1/64
1. Configure IPv6 addresses for the interfaces on each switch and unicast routing protocols.
2. Enable the unicast GR function on each switch and set the GR period.
3. Enable the multicast function, enable PIM-IPv6-SM on each interface of the switch, and
enable MLD on the interface connecting switch to the user host.
4. Configure an RP. Configure the same static RP on each switch.
5. Enable PIM GR on the switch where an active/standby switchover will occur and configure
the GR period.
Data Preparation

l Address of the multicast source S, which is 2001::1

l Address of the multicast group G, which is FF2E::1.
l Unicast GR period
l PIM GR period
Procedure
Step 1 Configure IPv6 addresses for the interfaces on each switch and unicast routing protocols.
# Configure an IPv6 address and mask for each interface on the switch based on Figure 13-2
and run OSPFv3 between switches to ensure that they can communicate with each other at the
network layer. The configuration details are not provided here.
Step 2 Enable the unicast GR function on each switch and set the GR period to 200s.
# Enable the unicast GR function on all the switches and set the unicast GR period to 200s. The
configurations of SwitchA and SwitchB are similar to the configuration of SwitchC, and are not
provided here.
[SwitchC] ospfv3 1
[SwitchC-ospfv3-1] graceful-restart
[SwitchC-ospfv3-1] graceful-restart period 200
[SwitchC-ospfv3-1] quit
Step 3 Enable the multicast function, enable PIM-IPv6-SM on each interface of the switch, and enable
MLD on the interface connecting switch to the user host.
# Enable the multicast function on all switches, and enable PIM SM on each interface of the
switch, and enable MLD on the interface connecting SwitchC to the host. The configurations of
SwitchA and SwitchB are similar to the configuration of SwitchC, and are not provided here.
[SwitchC] multicast ipv6 routing-enable
[SwitchC] interface Vlanif60
[SwitchC-Vlanif60] pim ipv6 sm
[SwitchC-Vlanif60] mld enable
[SwitchC] interface Vlanif50
[SwitchC-Vlanif50] pim ipv6 sm

# Create a loopback interface on SwitchA and enable PIM SM on the interface.
[SwitchA-Loopback0] ipv6 enable
[SwitchA-Loopback0] ipv6 address 2002:1::1 64
[SwitchA-Loopback0] pim ipv6 sm
[SwitchA-Loopback0] ospfv3 1 area 0
[SwitchA-Loopback0] quit
# Configure static RPs on all the switches. The configurations of SwitchC and SwitchB are
similar to the configuration of SwitchA, and are not provided here.
[SwitchA] pim-ipv6
[SwitchA-pim6] static-rp 2002:1::1
[SwitchA-pim6] quit
Step 5 Enable PIM GR and set the PIM GR period.

# Enable the PIM GR function on SwitchC and set the PIM GR period to 300s.
[SwitchC] pim-ipv6

[SwitchC-pim6] graceful-restart
[SwitchC-pim6] graceful-restart period 300
[SwitchC-pim6] quit
# Configure the multicast source (2001:1::1) to send data to the multicast group (FF2E::1) and
configure HostA to send an MLD Report message to the multicast group. Ensure that Receiver
can receive the data from the multicast source. Before SwitchC performs an active/standby
switchover, run the display pim ipv6 routing-table command on SwitchB and SwitchC to view
the multicast routing tables. The command output is as follows:
(*, FF2E::1)
RP: 2002:1::1
UpTime: 00:00:53
Upstream neighbor: FE80::E0:F2C:3C02:1
RPF prime neighbor: FE80::E0:F2C:3C02:1
1: Vlanif40
(2001:1::1, FF2E::1)
RP: 2002:1::1
UpTime: 00:21:24
1: Vlanif40
(*, FF2E::1)
RP: 2002:1::1
UpTime: 00:01:16
Upstream neighbor: FE80::5463:0:9245:2
RPF prime neighbor: FE80::5463:0:9245:2
1: Vlanif60
(2001:1::1, FF2E::1)
RP: 2002:1::1
UpTime: 00:01:16
1: Vlanif60
# Run the following command on SwitchC to perform an active/standby switchover.

[SwitchC] slave switchover
# After SwitchC performs an active/standby switchover, during PIM GR, run the display pim
ipv6 routing-table command on SwitchB and SwitchC to view the routing tables. The command
(*, FF2E::1)
RP: 2002:1::1
UpTime: 00:02:20
1: Vlanif40
(2001:1::1, FF2E::1)
RP: 2002:1::1
UpTime: 00:02:20
1: Vlanif40
(*, FF2E::1)
RP: 2002:1::1
UpTime: 00:02:44
1: Vlanif60
(2001:1::1, FF2E::1)
RP: 2002:1::1
UpTime: 00:02:44
1: Vlanif60
On a multicast network that runs normally, the downstream switch periodically sends Join/Prune
messages to the upstream to update the timeout period of PIM routing entries on the upstream
device, thereby ensuring normal multicast data forwarding.
If the GR function is not configured on SwitchC, the new master MPU deletes the multicast
forwarding entries of the LPUs, receives the IGMP Report messages sent by hosts, and creates
the PIM routing entries. In this process, multicast traffic is interrupted.

The preceding information indicates that after SwitchC performs an active/standby switchover,
the downstream interface on SwitchB remains unchanged. That is, after SwitchC performs an
active/standby switchover, SwitchC sends the backed up Join messages to the upstream device.
In this way, multicast forwarding entries can be maintained during GR to ensure nonstop
multicast data forwarding.
During the restoration of multicast routing entries on SwitchC, users can still receive multicast
data normally and services are not affected.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
ipv6
#
#
ospfv3 1
router-id 2.2.2.2
area 0.0.0.0
#
interface Vlanif10
ipv6 enable
ipv6 address 2001:2::1/64
ospfv3 1 area 0.0.0.0
pim ipv6 sm
#
interface Vlanif20
ipv6 enable
pim ipv6 sm
#
port hybrid tagged vlan10
#
#
interface LoopBack0
ipv6 enable
pim ipv6 sm
#
pim-ipv6
static-rp 2002:1::1
#
return

#
sysname SwitchB
#
vlan batch 30 40
#
ipv6

#
#
ospfv3 1
router-id 3.3.3.3
area 0.0.0.0
#
interface Vlanif30
ipv6 enable
pim ipv6 sm
interface Vlanif40
ipv6 enable
pim ipv6 sm
#
#
pim-ipv6
static-rp 2002:1::1
#
return
#
sysname SwitchC
#
vlan batch 50 60
#
ipv6
#
#
ospfv3 1
router-id 5.5.5.5
area 0.0.0.0
#
interface Vlanif50
ipv6 enable
pim ipv6 sm
interface Vlanif60
ipv6 enable
pim ipv6 sm
mld enable
#
#
pim-ipv6

static-rp 2002:1::1
graceful-restart
#
return

14 IPv6 Multicast Routing Management
About This Chapter
The system synchronously maintains multiple multicast routing protocols, and controls multicast
routing and forwarding through the information exchanged between the control plane and the
forwarding plane.
The system maintains a protocol routing table, multicast routing table, and multicast forwarding
table for multicast routing and forwarding. A multicast routing protocol creates multicast routing
entries through RPF.
14.2 IPv6 Multicast Routing Management Features Supported by the S9300
The IPv6 multicast routing management features supported by the system are: configuring IPv6
multicast routing policies, controlling the scope of multicast forwarding, controlling the
parameters of a multicast forwarding table, and configuring multicast splitting.
14.3 Configuring the IPv6 Multicast Routing Policy
Multicast routing policies can be implemented by configuring the IPv6 multicast load splitting
function and setting an IPv6 multicast load splitting weight.
14.4 Limiting the Range of Multicast Forwarding
scope. Therefore, configuring an IPv6 multicast forwarding boundary, setting the TTL threshold
of IPv6 multicast forwarding, and disabling an interface from receiving IPv6 multicast packets
are necessary for restricting the multicast data forwarding scope.
14.5 Configuring Control Parameters of the IPv6 Multicast Forwarding Table
traffic load on the multicast device is released and thus the fault risk resulted from excessive
entries can be avoided.
14.6 Maintaining IPv6 Multicast Routing Management
Maintaining IPv6 multicast routing management involves clearing IPv6 multicast forwarding
and routing entries, and monitoring IPv6 multicast routing and forwarding.

Configuration examples for IPv6 multicast load splitting are provided.


The system maintains a protocol routing table, multicast routing table, and multicast forwarding
table for multicast routing and forwarding. A multicast routing protocol creates multicast routing
entries through RPF.
In the IPv6 multicast network, PIM-IPv6 adopts the Reverse Path Forwarding (RPF) check,
creates, and updates routing entries, including the (*, G) entry and (S, G) entry. The RPF check
is implemented on the basis of RPF routes. IPv6 RPF routes are selected from unicast routes.
The multicast routing table records (S, G) entries and downloads the entries to the multicast
forwarding table. The multicast forwarding table directly guides the forwarding of multicast data
packets.
An (S, G) forwarding entry contains the following information:
l Source address S
l Group address G
l Incoming interface, which indicates that multicast data is received through this interface.
The incoming interface corresponds to the upstream interface of the related routing entry.
l Outgoing interface, which indicates that multicast data is sent out through this interface.
The outgoing interface corresponds to the downstream interface in the downstream
interface list of the related routing entry.
NOTE
IPv6 multicast forwarding and routing are similar to IPv4 multicast forwarding and routing. For details,
refer to the chapter "Multicast Forwarding and Routing" in the Quidway S9300 Terabit Routing Switch
Feature Description - IP Multicast.
14.2 IPv6 Multicast Routing Management Features

Supported by the S9300
The IPv6 multicast routing management features supported by the system are: configuring IPv6
multicast routing policies, controlling the scope of multicast forwarding, controlling the
parameters of a multicast forwarding table, and configuring multicast splitting.
Configuring the IPv6 Multicast Routing Policy

When a switch enabled with IPv6 multicast selects the upstream interface, you need to configure
the route selection policy if multiple equal-cost unicast routes exist. You can configure the
switch to select the route with the highest next-hop address or configure load splitting.
Performing multicast load splitting according to different policies can optimize network traffic
transmission in the scenario where multiple multicast data flows exist.
There are five multicast load splitting policies: stable-preferred, balance-preferred, source
address-based, group address-based, and source and group addresses-based. The five load
splitting policies are mutually exclusive. In stable-preferred mode and balance-preferred mode,
you can configure IPv6 load splitting weights on the interfaces to achieve unbalanced multicast
load splitting.

Limiting the Range of Multicast Forwarding

In the IPv6 network, the multicast information each multicast group corresponds to is transmitted
in a certain range. In the S9300, you can define the multicast forwarding range by using the
following methods:
l Configuring an IPv6 multicast forwarding boundary on an interface to form a closed

multicast forwarding area
l Setting the TTL threshold for IPv6 multicast forwarding on an interface to limit the range
in which an IPv6 multicast packet can be forwarded
Configuring Control Parameters of the IPv6 Multicast Forwarding Table

In network planning for multicast services, you can set limits on the number of entries in an IPv6
multicast forwarding table and number of downstream interfaces of a single forwarding entry
in the IPv6 multicast forwarding table.
14.3 Configuring the IPv6 Multicast Routing Policy

Multicast routing policies can be implemented by configuring the IPv6 multicast load splitting
function and setting an IPv6 multicast load splitting weight.

Before configuring IPv6 multicast routing policies, familiarize yourself with the applicable
If multiple unicast routes with the same cost exist when a switch enabled with IPv6 multicast
selects the upstream interface, you can use one of the following methods to configure the
switch to select the RPF route:
l By default, the switch selects the route with the highest next-hop address.
l Load splitting is configured among equal-cost routes. Performing load splitting of multicast
traffic according to different policies can optimize network traffic transmission in the
scenario where multiple multicast data flows exist.
Before configuring the IPv6 multicast routing policy, complete the following tasks:
l Configuring an IPv6 unicast routing protocol

Data Preparation
To configure the IPv6 multicast routing policy, you need the following data.

No. Data
1 IPv6 load splitting policy
2 IPv6 load splitting weight on the interface
14.3.2 Configuring IPv6 Multicast Load Splitting

on the RPF check. Performing load splitting of multicast traffic according to different policies
can optimize network traffic transmission in the scenario where multiple multicast data flows
exist. You can choose to configure a balance-preferred or stable-preferred load splitting policy.
Context
The IPv6 multicast load splitting function extends multicast routing rules, which does not fully
depend on the RPF check. If multiple equal-cost optimal routes exist over the network, they all
can be used for multicast data forwarding. In the case that the multicast service is guaranteed,
multicast traffic is load split to multiple equal-cost routes.
By default, IPv6 multicast load splitting is not configured.
Do as follows on the switch enabled with IPv6 multicast:
Procedure
Step 1 Run:
system-view
Step 2 Run:
multicast ipv6 load-splitting { balance-preferred | stable-preferred | source |
group | source-group }
IPv6 multicast splitting is configured.
Parameters in the command are described as follows:
l balance-preferred: indicates balance-preferred load splitting. This policy is applicable to

the scenario where hosts frequently join or leave the groups, which requires automatic load
adjustment.
If balance-preferred is specified, the switch automatically adjusts and balances the entries
on the equal-cost routes when equal-cost routes are added or deleted, IPv6 multicast routing
entries are deleted, or IPv6 load splitting weights on the interfaces are changed.
l stable-preferred: indicates stable-preferred load splitting. This policy is applicable to the
stable multicast networking.
If stable-preferred is specified, the switch automatically adjusts and balances the entries
when equal-cost routes are added or deleted; however, when IPv6 multicast routing entries
are deleted or IPv6 load splitting weights on the interfaces are changed, the switch does not
automatically adjust the entries on the equal-cost routes.

l group: indicates group address-based load splitting. This policy is applicable to the scenario
of one source to multiple groups.
l source: indicates source address-based load splitting. This policy is applicable to the scenario
of one group to multiple sources.
l source-group: indicates source and group addresses-based load splitting. This policy is
applicable to the scenario of multiple sources to multiple groups.
NOTE
It is recommended to adopt a fixed IPv6 multicast load splitting policy based on the actual networking.
The balance-preferred or stable-preferred policy is preferred.
balance-preferred or stable-preferred cannot be configured on the interface enabled with PIM-DM.
You can configure a multicast load splitting weight only in a stable-preferred load splitting or balance-
preferred load splitting scenario.

interface vlanif interface-number

multicast ipv6 load-splitting weight weight-value
The interface is configured with an IPv6 multicast load splitting weight.

By default, the IPv6 multicast load splitting weight of an interface is 1.
The greater the load splitting weight of an interface, the more IPv6 multicast routing entries with
this interface being the upstream interface. When the IPv6 multicast load splitting weight on an
----End
14.3.3 Configuring an IPv6 Multicast Load Splitting Weight

When an IPv6 multicast load splitting policy is configured, because the forwarding capabilities
of equal-cost routes are different from the actual load bearing situation on the equal-cost routes,
balanced load splitting cannot meet network requirements in some scenarios. In such a case, you
can configure a load splitting weight on an interface to achieve unbalanced multicast load
splitting.
Context
When stable-preferred or balance-preferred load splitting is configured, because the forwarding
capabilities of equal-cost routes are different from the actual load bearing situation on the equal-
cost routes, balanced load splitting cannot meet network requirements in some scenarios. In such
a case, you can configure an IPv6 multicast load splitting weight on an interface to achieve
unbalanced multicast load splitting.
Do as follows on the switch enabled with IPv6 multicast:
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
multicast ipv6 load-splitting weight weight-value
The interface is configured with an IPv6 multicast load splitting weight.
By default, the IPv6 multicast load splitting weight of an interface is 1.
The greater the load splitting weight of an interface, the more IPv6 multicast routing entries with
this interface being the upstream interface. When the IPv6 multicast load splitting weight on an
----End

After IPv6 multicast routing policies are configured, you can check information about the IPv6
multicast routing table and RPF routing information of a specified multicast source to ensure
normal running of the multicast network.
Procedure
l Run the display multicast ipv6 routing-table [ ipv6-source-address [ ipv6-source-mask-
length ] | ipv6-group-address [ ipv6-group-mask-length ] | incoming-interface { interface-
type interface-number | register } | outgoing-interface { { exclude | include | match }
{ interface-type interface-number | register | none } } ] * [ outgoing-interface-number
[ number ] ] command to check the IPv6 multicast routing table.
l Run the display multicast ipv6 rpf-info ipv6-source-address [ ipv6-group-address ]
[ rpt | spt ] command to display the IPv6 RPF routing information of a source-specific
multicast group.
----End
14.4 Limiting the Range of Multicast Forwarding

scope. Therefore, configuring an IPv6 multicast forwarding boundary, setting the TTL threshold
of IPv6 multicast forwarding, and disabling an interface from receiving IPv6 multicast packets
are necessary for restricting the multicast data forwarding scope.

Before configuring the IPv6 multicast data forwarding scope, familiarize yourself with the
applicable environment, pre-configuration tasks, and required data. This can help you complete
the configuration task quickly and accurately.

In the IPv6 network, the multicast information each multicast group corresponds to is transmitted
in a certain range. In the S9300, you can define the IPv6 multicast forwarding range by using
the following methods:
l Configuring an IPv6 multicast forwarding boundary on an interface to form a closed
multicast forwarding area. When an interface of a switch is configured with the forwarding
boundary for a group, the interface does not forward or receive any packet for the group.
Before limiting the range of multicast forwarding, complete the following tasks:
Data Preparation
To limit the range of multicast forwarding, you need the following data.
No. Data
1 Group address, mask, and mask length of the IPv6 multicast forwarding boundary
2 TTL threshold for IPv6 multicast forwarding
14.4.2 Configuring the IPv6 Multicast Forwarding Boundary on an

Interface
When an interface on a multicast device is configured with a forwarding boundary for a specified
group, the forwarding scope of IPv6 multicast packets is restricted.
Context
By default, the IPv6 multicast forwarding boundary is not set on an interface.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
multicast ipv6 boundary ipv6-group-address ipv6-group-mask-length

The IPv6 multicast forwarding boundary is configured.
----End

After the multicast forwarding scope is configured, you can check information about the IPv6
multicast routing table, IPv6 multicast boundary of an interface, and TTL threshold of the IPv6
multicast packets forwarded on an interface to ensure normal running of the multicast network.
Procedure
[ number ] ] command to check the IPv6 multicast routing table.
l Run the display multicast ipv6 boundary [ ipv6-group-address [ ipv6-group-mask-
length ] ] [ interface interface-type interface-number ] command to check the IPv6
multicast boundary configured on the interface.
----End
14.5 Configuring Control Parameters of the IPv6 Multicast

Forwarding Table
traffic load on the multicast device is released and thus the fault risk resulted from excessive
entries can be avoided.

Before configuring control parameters for the multicast forwarding table, familiarize yourself
with the applicable environment, pre-configuration tasks, and required data. This can help you
complete the configuration task quickly and accurately.
When planning a specific network according to network services, the ISP needs to perform the
following configurations:
l Limiting the number of entries in the IPv6 multicast forwarding table
A switch maintains a forwarding entry for each received multicast packet. Too many
multicast forwarding entries, however, use up the memory of the switch. You can define
the maximum number of entries in the multicast forwarding table of a switch. Limiting the
number of entries according to the actual networking and service performance can prevent
faults caused by too many entries.
l Limiting the number of downstream interfaces of a single forwarding entry
A switch replicates a multicast packet for each downstream interface and sends them out.
Each downstream interface forms a branch of a multicast distribution tree (MDT). The

number of downstream interfaces determines the maximum scale of an MDT and the service
range. You can define the number of downstream interfaces of a single forwarding entry.
Limiting the number of downstream interfaces according to the actual networking and
service performance can reduce the processing pressure of a switch and control the service
range.
Before configuring control parameters of the IPv6 multicast routing policy, complete the
following tasks:
Data Preparation
To configure control parameters of the IPv6 multicast routing policy, complete the following
tasks.
No. Data
1 Source address, group address, and mask or mask length
2 Matching policy, sequence, and preference of multicast routes
3 The maximum number of forwarding entries in the multicast forwarding table
4 The maximum number of downstream interfaces of each forwarding entry in the

multicast forwarding table
14.5.2 Configuring the Maximum Number of Entries in the IPv6

Multicast Forwarding Table
Too many multicast forwarding entries may use up the memory of a multicast device. You can
set the maximum number of entries in a multicast forwarding table of a multicast device and
adjust the number of entries according to the actual networking and service performance to
prevent the faults resulted from excessive entries.
Context
By default, the maximum value permitted by the system is used.
Procedure
Step 1 Run:
system-view

Step 2 Run:
multicast ipv6 forwarding-table route-limit limit-value

The maximum number of entries in the IPv6 multicast forwarding table is set.
----End
14.5.3 Configuring the Maximum Number of Downstream Nodes

of a Single Forwarding Entry
A multicast device replicates a copy of multicast packets for each downstream interface. Then,
you can set the number of downstream interfaces of a single forwarding entry and adjust the
number of downstream interfaces according to the actual networking and service performance
to release the burden on the multicast device.
Context
By default, the maximum value permitted by the system is used.
Procedure
Step 1 Run:
system-view
Step 2 Run:
multicast ipv6 forwarding-table downstream-limit limit-value
The maximum number of downstream nodes of a single entry in the IPv6 multicast forwarding
table is set.
----End

After control parameters for the multicast forwarding table are configured, you can check
information about the multicast routing table to ensure normal running of the multicast network.
Procedure
l Run the display multicast ipv6 forwarding-table [ ipv6-source-address [ ipv6-source-
mask-length ] | ipv6-group-address [ ipv6-group-mask-length ] | incoming-interface
{ interface-type interface-number | register } | outgoing-interface { { exclude | include |
match } { interface-type interface-number | register | none } } | statistics ] * command to
check the IPv6 multicast forwarding table.
----End
14.6 Maintaining IPv6 Multicast Routing Management

Maintaining IPv6 multicast routing management involves clearing IPv6 multicast forwarding
and routing entries, and monitoring IPv6 multicast routing and forwarding.

14.6.1 Clearing IPv6 Multicast Forwarding Entries and Routing

Entries
After you confirm to clear IPv6 multicast forwarding and routing entries, use the reset command
in the user view. After you run the reset command to clear information in the multicast
forwarding table and the multicast routing table, multicast data cannot be normally transmitted.
So, confirm the action before you use the command.
Context
CAUTION
After you run the reset command to clear information in the multicast forwarding table or in the
multicast routing table, multicast data cannot be normally transmitted. So, confirm the action
Procedure
l Run the reset multicast ipv6 forwarding-table { ipv6-group-address [ ipv6-group-mask-
length ] | ipv6-source-address [ ipv6-source-mask-length ] | incoming-interface
{ interface-type interface-number | register } } * command in the user view to clear the
forwarding entry in the IPv6 multicast forwarding table.
l Run the reset multicast ipv6 routing-table { ipv6-source-address [ ipv6-source-mask-
type interface-number | register } } * command in the user view to clear the routing entry
in the IPv6 multicast routing table.
----End
14.6.2 Monitoring the Running Status of IPv6 Multicast Forwarding

and Routing
During the routine maintenance of IPv6 multicast routing management, you can run the display
commands in any view to know the running of the multicast forwarding table and routing table.
Context
status of IPv6 multicast forwarding and routing.
Procedure
l Run the display multicast ipv6 boundary [ ipv6-group-address [ ipv6-group-mask-
length ] ] [ interface interface-type interface-number ] command in any view to check
information about boundaries of all interfaces.
l Run the display multicast ipv6 forwarding-table [ ipv6-source-address [ ipv6-source-
mask-length ] | ipv6-group-address [ ipv6-group-mask-length ] | incoming-interface
{ interface-type interface-number | register } | outgoing-interface { { exclude | include |

match } { interface-type interface-number | register | none } } | statistics ] * command in

any view to check the IPv6 multicast forwarding table.
[ number ] ] command in any view to check the IPv6 multicast routing table.
l Run the display multicast ipv6 rpf-info ipv6-source-address [ ipv6-group-address ]
[ rpt | spt ] command in any view to check the RPF routes of a specified multicast source.
----End
14.6.3 Debugging IPv6 Multicast Forwarding and Routing

When a fault occurs during IPv6 multicast routing management, run the debugging commands
Context
CAUTION
all command to disable the debugging immediately.
When an IPv6 multicast fault occurs, run the following debugging commands in the user view
to view debugging information and locate the fault.
Procedure
l Run the debugging mfib ipv6 { all | module | no-cache | packet | register | route | sync
| upcall | wrong-iif } [ advanced-acl6-number ]* command in the user view to enable the
debugging of IPv6 multicast forwarding.
l Run the debugging mrm ipv6 { all | event | packet [ advanced-acl6-number ] | route
[ advanced-acl6-number ] } command in the user view to enable the debugging of IPv6
multicast routing management.
----End

Configuration examples for IPv6 multicast load splitting are provided.
14.7.1 Example for Configuring IPv6 Multicast Load Splitting

RPF check is the basis of route selection and unicast routes are used to forward multicast traffic.
According to RPF check, a unique route is selected to guide the forwarding of multicast data. If
multicast traffic is heavy, network congestion may occur and multicast services are affected.
Multicast load splitting extends the multicast route selection rule and is independent of RPF
check. If there are multiple optimal equal-cost routes on a network, they may be used to forward
multicast data. Multicast traffic can be load balanced amount multiple equal-cost routes.
Currently, multicast load splitting can be performed based on the source address, group address,
and source group address, without meeting requirements of load splitting in all the scenarios. If
multicast routing entries and network configurations are stable, RPF interfaces and RPF
neighbors remain unchanged. If a few multicast routing entries are used, traffic among equal-
cost routes may be distributed unevenly.
The stable-preferred multicast load splitting policy offsets the disadvantages of the preceding
load splitting policies. As shown in Figure 14-1, three equal-cost routes are available from
SwitchE connected to HostA to the multicast source. The stable-preferred multicast load splitting
policy is configured on SwitchE so that entries are evenly distributed to the three equal-cost
routes. Load splitting among equal-cost routes is implemented.
If forwarding capabilities or traffic congestion degrees of the three equal-cost routes of

SwitchE are different, multicast entries cannot be load balanced. You need to configure uneven
load splitting on SwitchE, set different load splitting routes for upstream interfaces, and change
the number of multicast entries on the equal-cost routes. In this manner, multicast entries on the
equal-cost routes can be controlled flexibly.
Figure 14-1 Networking diagram for configuring multicast load splitting
PIM-SM
Source
0 /1 1 /0 /0 GE2 GE1/0/
/ 1
GE1/0/0 GE 2 GE SwitchB /0/0
GE2/0/2 GE1/0/2 GE2/0/0
SwitchA GE2
/0 /3 GE1/0/0 GE2/0/0
SwitchC /0 /3
GE1 SwitchE
GE1
/0 /0 /0 /0 HostA
Loopback0 GE2
SwitchD
Switch Interface IP Address Device Interface IP Address
SwitchA GE1/0/0 2001::2/64 SwitchC GE1/0/0 2003::2/64
VLANIF10 VLANIF70
GE2/0/1 2002::1/64 GE2/0/0 2006::1/64
VLANIF20 VLANIF80

GE2/0/2 2003::1/64 SwitchD GE1/0/0 2004::2/64
VLANIF30 VLANIF90
GE2/0/3 2004::1/64 GE2/0/0 2007::1/64
VLANIF40 VLANIF100
LoopBack0 2000::1/64 SwitchE GE1/0/1 2005::2/64
VLANIF110
SwitchB GE1/0/0 2002::2/64 GE1/0/2 2006::2/64
VLANIF50 VLANIF120
GE2/0/0 2005::1/64 GE1/0/3 2007::2/64
VLANIF60 VLANIF130
GE2/0/0 3001::1/64
VLANIF140
l Assign IPv6 addresses to interfaces on switches.
l Configure IS-IS IPv6 to implement interworking among switches and ensure that route
costs are the same.
l Enable multicast on switches, enable IPv6 PIM-SM on each interface, and set the loopback
interface on SwitchA as an RP.
l Configure stable-preferred IPv6 multicast load splitting on SwitchE to ensure the stability
of IPv6 multicast services.
l Host A needs to receive data from some multicast groups for a long period. Configure the
interfaces on the host side of SwitchE to statically join multicast groups in batches.
l Host A needs to receive data from a new multicast group. According to networking
requirements, set different IPv6 multicast load splitting weights for upstream interfaces on
SwitchE to ensure that IPv6 multicast traffic is distributed unevenly.
Data Preparation
l IPv6 address of the multicast source
l IPv6 addresses of interfaces on switches
l Address of the multicast group that interfaces on the host side of SwitchE statically join in
batches
l IPv6 multicast load splitting weights of upstream interfaces on SwitchE

Procedure
Step 1 Assign IP addresses to interfaces on all the switches according to Figure 14-1. The configuration
Step 2 Configure IS-IS IPv6 to implement interworking among switches and ensure that route costs are
the same. The configuration details are not provided here.
Step 3 Enable IPv6 multicast on all switches and enable IPv6 PIM-SM on each interface.
# Configure SwitchA. The configurations on SwitchB, SwitchC, SwitchD, and SwitchE are
similar to those on SwitchA, and are not provided here.
[SwitchA-LoopBack0] pim ipv6 sm
[SwitchA-LoopBack0] quit
Step 4 Configure an RP on SwitchA.

# Configure Loopback0 on SwitchA as an RP.
[SwitchA] pim-ipv6
[SwitchA-pim6] c-bsr 2000::1
[SwitchA-pim6] c-rp 2000::1
[SwitchA-pim6] quit
Step 5 Configure stable-preferred IPv6 multicast load splitting on SwitchE.

[SwitchE] multicast ipv6 load-splitting stable-preferred
Step 6 Configure interfaces on the host side of SwitchE to statically join the multicast groups in batches.
# Configure VLANIF140 to statically join multicast groups from FF13::1 to FF13::3.
[SwitchE-Vlanif140] mld static-group ff13::1 inc-step-mask 128 number 3
Step 7 Verify the configuration about stable-preferred IPv6 multicast load splitting.
# The multicast source (2001::1/64) sends multicast data to multicast groups (FF13::1 to
FF13::3). Host A can receive the multicast data from the multicast source. On SwitchE, check
brief information about the IPv6 PIM routing table.
<SwitchE> display pim ipv6 routing-table brief
00001.(*, FF13::1)
Upstream interface:Vlanif110
Number of downstream:1
00002.(2001::1, FF13::1)

00003.(*, FF13::2)
00004.(2001::1, FF13::2)
00005.(*, FF13::3)
00006.(2001::1, FF13::3)
(*, G) and (S, G) entries are evenly distributed to the three equal-cost routes, with the upstream
interfaces being VLANIF110, VLANIF120, and VLANIF130.
NOTE
The load splitting algorithm processes (*, G) and (S, G) entries separately with the same processing rule.
Step 8 Set different IPv6 multicast load splitting weights for upstream interfaces of SwitchE to ensure
that multicast traffic is distributed unevenly.
# Set the IPv6 multicast load splitting weight on VLANIF110 to 2.
[SwitchE-Vlanif110] multicast ipv6 load-splitting weight 2
# Set the IPv6 multicast load splitting weight on VLANIF130 to 0.

[SwitchE-Vlanif130] multicast ipv6 load-splitting weight 0
Step 9 Configure interfaces on the host side of SwitchE to statically join new multicast groups in
batches.
# Configure VLANIF140 to statically join multicast groups from FF13::4 to FF13::9.
[SwitchE-Vlanif140] mld static-group ff13::4 inc-step-mask 128 number 6
Step 10 Verify the configuration about uneven IPv6 multicast load splitting.
# The multicast source (2001::1/64) sends multicast data to multicast groups (FF13::1 to
FF13::9). Host A can receive the multicast data from the multicast source. On SwitchE, check
brief information about the IPv6 PIM routing table.
<SwitchE> display pim ipv6 routing-table brief
00001.(*, FF13::1)
00002.(2001::1, FF13::1)
00003.(*, FF13::2)
00004.(2001::1, FF13::2)
00005.(*, FF13::3)

00006.(2001::1, FF13::3)
00007.(*, FF13::4)
00008.(2001::1, FF13::4)
00009.(*, FF13::5)
00010.(2001::1, FF13::5)
00011.(*, FF13::6)
00012.(2001::1, FF13::6)
00013.(*, FF13::7)
00014.(2001::1, FF13::7)
00015.(*, FF13::8)
00016.(2001::1, FF13::8)
00017.(*, FF13::9)
00018.(2001::1, FF13::9)
The upstream interfaces of existing (*, G) and (S, G) entries keep unchanged. The IPv6 multicast
load splitting weight of VLANIF110 is greater than that of VLANIF120; therefore, the newly
generated entries with the upstream interface being VLANIF110 are more than those with the
upstream interface being VLANIF120. The IPv6 multicast load splitting weight of VLANIF130
is 0, indicating that VLANIF130 does not load balance new entries.
----End
Configuration Files
l Configuration file of SwitchA.
#
sysname SwitchA
#
vlan batch 10 20 30 40
#
ipv6
#
#
isis 1
network-entity 10.0000.0000.0001.00
#
ipv6 enable topology standard
#
interface Vlanif10

ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
#
interface Vlanif20
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
#
interface Vlanif30
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
#
interface Vlanif40
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
#
#
#
#
#
interface LoopBack0
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
#
pim-ipv6
c-bsr 2000::1
c-rp 2000::1
#
return
l Configuration file of SwitchB.
#
sysname SwitchB
#
vlan batch 50 60
#
ipv6
#
#
isis 1
network-entity 10.0000.0000.0002.00
#
#
interface Vlanif50
ipv6 enable
isis ipv6 enable 1

pim ipv6 sm
#
interface Vlanif60
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
#
#
#
return
l Configuration file of SwitchC.
#
sysname SwitchC
#
vlan batch 70 80
#
ipv6
#
#
isis 1
network-entity 10.0000.0000.0003.00
#
#
interface Vlanif70
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
#
interface Vlanif80
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
#
#
#
return
l Configuration file of SwitchD.
#
sysname SwitchD
#
vlan batch 90 100
#
ipv6
#
#
isis 1
network-entity 10.0000.0000.0004.00
#
#

interface Vlanif90
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
#
interface Vlanif100
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
#
#
#
return
l Configuration file of SwitchE.
#
sysname SwitchE
#
vlan batch 110 120 130 140
#
ipv6
#
multicast ipv6 load-splitting stable-preferred
#
isis 1
network-entity 10.0000.0000.0005.00
#
#
interface Vlanif110
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
multicast ipv6 load-splitting weight 2
#
interface Vlanif120
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
#
interface Vlanif130
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
multicast ipv6 load-splitting weight 0
#
interface Vlanif140
ipv6 enable
isis ipv6 enable 1
pim ipv6 sm
mld static-group FF13::1 inc-step-mask 128 number 3
mld static-group FF13::4 inc-step-mask 128 number 6
#
#

#
#
#
return


Configuration Guide - Multicast (V100R006C00 - 02) PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configuration Guide - Multicast (V100R006C00 - 02) PDF

Uploaded by

Copyright:

Available Formats

Quidway S9300 Terabit Routing Switch

Configuration Guide - Multicast

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2011-07-15) Huawei Proprietary and Confidential i

About This Document

This document is intended for:

l Data configuration engineer

Indicates a hazard with a high level of risk, which if not

Indicates a hazard with a medium or low level of risk, which

Indicates a potentially hazardous situation, which if not

NOTE Provides additional information to emphasize or supplement

Issue 02 (2011-07-15) Huawei Proprietary and Confidential ii

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

[ 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

# A line starting with the # sign is comments.

Changes in Issue 02 (2011-07-15)

Changes in Issue 01 (2011-05-20)

Issue 02 (2011-07-15) Huawei Proprietary and Confidential iii

About This Document.....................................................................................................................ii

2 IGMP Snooping Configuration................................................................................................10

Issue 02 (2011-07-15) Huawei Proprietary and Confidential iv

2.4 Configuring Static Layer 2 Multicast...............................................................................................................25

3 Multicast VLAN Replication Configuration..........................................................................53

Issue 02 (2011-07-15) Huawei Proprietary and Confidential v

3.4.1 Establishing the Configuration Task.......................................................................................................59

Issue 02 (2011-07-15) Huawei Proprietary and Confidential vi

4.8.1 Example for Configuring Basic IGMP Functions...................................................................................89

5 PIM-DM (IPv4) Configuration................................................................................................104

Issue 02 (2011-07-15) Huawei Proprietary and Confidential vii

5.9.2 Configuring the Period for Keeping the Assert State............................................................................131

6 PIM-SM (IPv4) Configuration................................................................................................144

Issue 02 (2011-07-15) Huawei Proprietary and Confidential viii

6.7 Adjusting Control Parameters for Establishing the Neighbor Relationship...................................................167

Issue 02 (2011-07-15) Huawei Proprietary and Confidential ix

Issue 02 (2011-07-15) Huawei Proprietary and Confidential x

7.8.2 Encapsulating a Multicast Data Packet in an SA message....................................................................248

8 IPv4 Multicast VPN Configuration........................................................................................284

Issue 02 (2011-07-15) Huawei Proprietary and Confidential xi

8.6 Configuration Examples.................................................................................................................................295

9 IPv4 Multicast Routing Management....................................................................................319

Issue 02 (2011-07-15) Huawei Proprietary and Confidential xii

10.3.5 (Optional) Configuring an Interface to Statically Join a Group..........................................................362

11 MLD Snooping Configuration..............................................................................................387

Issue 02 (2011-07-15) Huawei Proprietary and Confidential xiii

11.4.2 Configuring a Multicast Group Policy................................................................................................395

12 PIM-DM (IPv6) Configuration..............................................................................................417

Issue 02 (2011-07-15) Huawei Proprietary and Confidential xiv

12.4.4 Checking the Configuration.................................................................................................................425

13 PIM-SM (IPv6) Configuration..............................................................................................452

Issue 02 (2011-07-15) Huawei Proprietary and Confidential xv

13.3 Configuring Basic PIM-SM (IPv6) Functions..............................................................................................456

Issue 02 (2011-07-15) Huawei Proprietary and Confidential xvi

13.9.1 Establishing the Configuration Task...................................................................................................485

14 IPv6 Multicast Routing Management..................................................................................513

Issue 02 (2011-07-15) Huawei Proprietary and Confidential xvii

14.6.1 Clearing IPv6 Multicast Forwarding Entries and Routing Entries......................................................524