Configuration Guide - Multicast (V100R006C01 - 01)

Quidway S5700 Series Ethernet Switches
V100R006C01
Configuration Guide - Multicast
Issue 01
Date 2011-10-26
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: [email protected]
Issue 01 (2011-10-26) 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 S5700, including basic
knowledge, protocol implementation, configuration procedures, and configuration examples.
This document guides you through the configuration of the multicast service of the S5700.
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 01 (2011-10-26) 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 01 (2011-10-26)

Initial commercial release.
Issue 01 (2011-10-26) 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 S5700..................................................................................................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
2 IGMP Snooping Configuration..................................................................................................6

2.1 IGMP Snooping Overview.................................................................................................................................7
2.2 IGMP Snooping Supported by the S5700..........................................................................................................8
2.3 Configuring IGMP Snooping.............................................................................................................................9
2.3.1 Establishing the Configuration Task.........................................................................................................9
2.3.2 Enabling IGMP Snooping.......................................................................................................................10
2.3.3 (Optional) Configuring a Static Router Interface....................................................................................12
2.3.4 (Optional) Configuring Multicast Group Member Interfaces.................................................................12
2.3.5 (Optional) Configuring IGMP Snooping Querier...................................................................................14
2.3.6 (Optional) Setting the Maximum Number of Multicast Groups that Hosts Attached to an Interface Can
Join....................................................................................................................................................................15
2.3.7 (Optional) Configuring Multicast Policies..............................................................................................16
2.3.8 (Optional) Setting the Suppression Time of IGMP Messages................................................................16
2.3.9 (Optional) Enabling the Discarding of Unknown Multicast Data Packets in a VLAN...........................17
2.3.10 (Optional) Configuring the S5700 to Actively Send IGMP Query Messages......................................18
2.3.11 (Optional) Configuring Router Alert Options in IGMP Messages........................................................18
2.3.12 (Optional) Configuring the IGMP Snooping Proxy for the VLAN.......................................................19
2.3.13 (Optional) Filtering Layer 2 Multicast Data on an Interface.................................................................20
2.3.14 Checking the Configuration...................................................................................................................20
2.4 Configuring a Static Multicast MAC Address.................................................................................................22
2.5 Configuring Layer 2 Multicast SSM Mapping.................................................................................................24
2.5.1 Establishing the Configuration Task.......................................................................................................24
2.5.2 (Optional) Configuring an SSM Group Policy........................................................................................25
2.5.3 (Optional) Configuring Layer 2 Multicast SSM Mapping......................................................................25
Issue 01 (2011-10-26) Huawei Proprietary and Confidential iv

2.5.4 Checking the Configuration.....................................................................................................................26

2.6 Maintaining Layer 2 Multicast.........................................................................................................................27
2.6.1 Clearing Static Entries in a Multicast Forwarding Table........................................................................27
2.6.2 Clearing Multicast Forwarding Entries...................................................................................................28
2.6.3 Clearing the Statistics on IGMP Snooping..............................................................................................28
2.6.4 Debugging IGMP Snooping....................................................................................................................28
2.7 Configuration examples....................................................................................................................................29
2.7.1 Example for Configuring IGMP Snooping.............................................................................................29
2.7.2 Example for Configuring IGMP Snooping SSM Mapping.....................................................................32
3 Multicast VLAN Replication Configuration..........................................................................36

3.1 Multicast VLAN Replication Overview...........................................................................................................37
3.2 Multicast VLAN Replication Supported by the S5700....................................................................................37
3.3 Configuring Multicast VLAN Replication Based on User VLANs.................................................................39
3.3.2 Configuring Multicast VLAN Replication Based on User VLANs........................................................40
3.3.3 Adding Interfaces to VLANs...................................................................................................................41
3.4 Configuring Multicast VLAN Replication Based on Interfaces.......................................................................42
3.4.2 Creating a Multicast VLAN....................................................................................................................43
3.4.3 Binding User VLANs to a Multicast VLAN on an Interface..................................................................43
3.4.4 Adding Interfaces to VLANs...................................................................................................................43
3.5 Configuring Many-to-Many Multicast VLAN Replication..............................................................................44
3.5.2 Enabling a User VLAN to Be Added to Multiple Multicast VLANs.....................................................45
3.5.3 Adding a User VLAN to Multiple Multicast VLANs.............................................................................46
3.5.4 (Optional) Configuring a Static Flow in a Multicast VLAN...................................................................47
3.6 Configuration Examples...................................................................................................................................48
3.6.1 Example for Configuring Multicast VLAN Replication Based on User VLANs...................................48
3.6.2 Example for Configuring Multicast VLAN Replication Based on Interfaces.........................................51
3.6.3 Example for Configuring Many-to-Many Multicast VLANs..................................................................54
4 Controllable Multicast Configuration.....................................................................................58

4.1 Overview of Controllable Multicast.................................................................................................................59
4.2 Basic Principle..................................................................................................................................................59
4.3 Configuring Controllable Multicast..................................................................................................................60
4.3.2 Configuring a Multicast Group................................................................................................................61
4.3.3 Configuring a Multicast Group List........................................................................................................61
4.3.4 Configuring a Multicast Profile...............................................................................................................62
4.3.5 Applying a Multicast Profile to a VLAN................................................................................................63
Issue 01 (2011-10-26) Huawei Proprietary and Confidential v


4.4 Configuration Example.....................................................................................................................................64
4.4.1 Example for Configuring Controllable Multicast....................................................................................64
5 IGMP Configuration...................................................................................................................68
5.1 Introduction to IGMP.......................................................................................................................................69
5.2 IGMP Features Supported by the S5700..........................................................................................................69
5.3 Configuring Basic IGMP Functions.................................................................................................................70
5.3.2 Enabling IP Multicast..............................................................................................................................71
5.3.3 Enabling the IGMP Function...................................................................................................................72
5.3.4 (Optional) Specifying the IGMP Version................................................................................................72
5.3.5 (Optional) Configuring a Static IGMP Group.........................................................................................73
5.3.6 (Optional) Configuring an IGMP Multicast Group Policy......................................................................73
5.4 Setting the Parameters of IGMP Features........................................................................................................75
5.4.2 Configuring IGMP Message Options......................................................................................................76
5.4.3 Configuring the IGMPv1 Querier............................................................................................................77
5.4.4 Configuring the IGMPv2 or IGMPv3 Querier........................................................................................79
5.4.5 Configuring IGMP Prompt Leave...........................................................................................................81
5.5 Configuring SSM Mapping..............................................................................................................................83
5.5.2 Enabling SSM Mapping..........................................................................................................................84
5.5.3 Configuring the SSM Mapping Policy....................................................................................................84
5.6 Maintaining IGMP............................................................................................................................................85
5.6.1 Clearing the Information About an IGMP Group...................................................................................85
5.6.2 Monitoring the Running Status of IGMP................................................................................................86
5.6.3 Debugging IGMP....................................................................................................................................86
5.7 Configuration Examples...................................................................................................................................87
5.7.1 Example for Configuring Basic IGMP Functions...................................................................................87
5.7.2 Example for Configuring SSM Mapping................................................................................................91
6 PIM-DM (IPv4) Configuration..................................................................................................98

6.1 PIM-DM Overview.........................................................................................................................................100
6.2 PIM-DM Features Supported by the S5700...................................................................................................101
6.3 Configuring Basic PIM-DM Functions..........................................................................................................102
6.3.1 Establishing the Configuration Task.....................................................................................................102
6.3.2 Enabling IPv4 Multicast Routing..........................................................................................................102
6.3.3 Enabling PIM-DM.................................................................................................................................103
6.4 Adjusting Control Parameters of a Multicast Source.....................................................................................104
Issue 01 (2011-10-26) Huawei Proprietary and Confidential vi


6.4.2 Configuring the Lifetime of a Source....................................................................................................105
6.4.3 Configuring Filtering Rules Based on Source Addresses.....................................................................106
6.5 Adjusting Control Parameters for Maintaining Neighbor Relationships.......................................................107
6.5.2 Configuring the Interval for Sending Hello Messages..........................................................................108
6.5.3 Configuring the Timeout Period of a Neighbor.....................................................................................109
6.5.4 Refusing to Receive the Hello Message Without the Generation ID Option........................................110
6.5.5 Configuring PIM Neighbor Filtering.....................................................................................................110
6.6 Adjusting Control Parameters for Prune........................................................................................................111
6.6.2 Configuring the Period for an Interface to Keep the Prune State..........................................................112
6.6.3 Configuring the Delay for Transmitting Prune Messages in a LAN.....................................................113
6.6.4 Configuring the Interval for Overriding the Prune Action....................................................................114
6.7 Adjusting Control Parameters for State-Refresh............................................................................................116
6.7.2 Disabling State-Refresh.........................................................................................................................116
6.7.3 Configuring the Interval for Sending State-Refresh Messages.............................................................117
6.7.4 Configuring the Period for Receiving the Next State-Refresh Message...............................................118
6.7.5 Configuring the TTL Value Carried in a State-Refresh Message.........................................................118
6.8 Adjusting Control Parameters for Graft.........................................................................................................120
6.8.2 Configuring the Interval for Retransmitting Graft Messages................................................................120
6.9 Adjusting Control Parameters for Assert........................................................................................................122
6.9.2 Configuring the Period for Keeping the Assert State............................................................................122
6.10 Configuring PIM Silent................................................................................................................................124
6.10.1 Establishing the Configuration Task...................................................................................................124
6.10.2 Configuring PIM Silent.......................................................................................................................125
6.10.3 Checking the Configuration.................................................................................................................126
6.11 Maintaining PIM-DM (IPv4)........................................................................................................................127
6.11.1 Clearing Statistics of PIM Control Messages......................................................................................127
6.11.2 Monitoring the Running Status of PIM...............................................................................................127
6.11.3 Debugging PIM...................................................................................................................................128
6.12 Configuration Example.................................................................................................................................129
6.12.1 Example for Configuring the PIM-DM Network................................................................................129
Issue 01 (2011-10-26) Huawei Proprietary and Confidential vii

7 PIM-SM (IPv4) Configuration................................................................................................135

7.1 PIM-SM Overview.........................................................................................................................................137
7.2 PIM-SM Features Supported by the S5700....................................................................................................138
7.3 Configuring Basic PIM-SM Functions...........................................................................................................140
7.3.2 Enabling IP Multicast Routing..............................................................................................................141
7.3.3 Enabling Basic PIM-SM Functions.......................................................................................................141
7.3.4 (Optional) Configuring a Static RP.......................................................................................................142
7.3.5 (Optional) Configuring a Dynamic RP..................................................................................................143
7.3.6 (Optional) Configuring the SSM Group Address Range.......................................................................144
7.4 Adjusting Control Parameters for a Multicast Source....................................................................................146
7.4.2 Configuring the Lifetime of a Source....................................................................................................147
7.4.3 Configuring Filtering Rules Based on Source Addresses.....................................................................147
7.5 Adjusting Control Parameters of the C-RP and C-BSR.................................................................................148
7.5.2 Adjusting C-RP Parameters...................................................................................................................149
7.5.3 Adjusting C-BSR Parameters................................................................................................................150
7.5.4 Configuring the BSR Boundary............................................................................................................151
7.5.5 (Optional) Configuring the BSR Address Range..................................................................................152
7.5.6 (Optional) Configuring the Range of Valid C-RP Addresses...............................................................152
7.6 Configuring a BSR Administrative Domain..................................................................................................153
7.6.2 Enabling a BSR Administrative Domain...............................................................................................154
7.6.3 Configuring the Boundary of a BSR Administrative Domain..............................................................155
7.6.4 Adjusting C-BSR Parameters................................................................................................................155
7.7 Adjusting Control Parameters for Establishing the Neighbor Relationship...................................................157
7.7.2 Configuring Control Parameters for Establishing the Neighbor Relationship......................................158
7.7.3 Configuring Control Parameters for Electing a DR..............................................................................159
7.7.4 Enabling the Function of Tracking a Downstream Neighbor................................................................161
7.7.5 Configuring PIM Neighbor Filtering.....................................................................................................162
7.8 Adjusting Control Parameters for Source Registering...................................................................................163
7.8.2 Configuring PIM-SM Register Messages..............................................................................................164
7.8.3 Configuring PIM-SM Register Suppression..........................................................................................164
Issue 01 (2011-10-26) Huawei Proprietary and Confidential viii

7.9 Adjusting Control Parameters for Forwarding...............................................................................................165

7.9.2 Configuring Control Parameters for Keeping the Forwarding State.....................................................166
7.9.3 Configuring Control Parameters for Prune............................................................................................168
7.9.4 Configuring Join Information Filtering.................................................................................................169
7.9.5 Configuring Neighbor Check................................................................................................................170
7.10 Adjusting Control Parameters for Assert......................................................................................................171
7.10.2 Configuring the Period for Keeping the Assert State..........................................................................172
7.11 Configuring the SPT Switchover..................................................................................................................173
7.11.2 (Optional) Configuring the Interval for Checking the Forwarding Rate of Multicast Data................175
7.12 Configuring PIM BFD..................................................................................................................................176
7.12.2 Configuring PIM BFD.........................................................................................................................177
7.12.3 (Optional) Adjusting BFD Parameters................................................................................................177
7.13 Configuring PIM Silent................................................................................................................................178
7.13.2 Configuring PIM Silent.......................................................................................................................179
7.14 Maintaining PIM-SM (IPv4)........................................................................................................................181
7.14.1 Clearing Statistics of PIM Control Messages......................................................................................181
7.14.2 Clearing the PIM Status of the Specified Downstream Interfaces of PIM Entries.............................181
7.14.3 Monitoring the Running Status of PIM-SM........................................................................................182
7.14.4 Debugging PIM...................................................................................................................................183
7.15 Configuration Examples...............................................................................................................................183
7.15.1 Example for Configuring the PIM-SM Network.................................................................................184
7.15.2 Example for Configuring PIM BFD....................................................................................................193
8 MSDP Configuration................................................................................................................198
8.1 MSDP Overview.............................................................................................................................................200
8.2 MSDP Features Supported by the S5700.......................................................................................................200
8.3 Configuring PIM-SM Inter-domain Multicast...............................................................................................202
8.3.2 Configuring Intra-AS MSDP Peers.......................................................................................................203
8.3.3 Configuring Inter-AS MSDP Peers on MBGP Peers............................................................................204
8.3.4 Configuring Static RPF Peers................................................................................................................205
8.4 Configuring an Anycast RP in a PIM-SM Domain........................................................................................207
Issue 01 (2011-10-26) Huawei Proprietary and Confidential ix


8.4.2 Configuring the Interface Address of an RP.........................................................................................208
8.4.3 Configuring a C-RP...............................................................................................................................209
8.4.4 Statically Configuring an RP.................................................................................................................210
8.4.5 Configuring an MSDP Peer...................................................................................................................210
8.4.6 Specifying the Logical RP Address for an SA Message.......................................................................211
8.5 Managing MSDP Peer Connections...............................................................................................................213
8.5.2 Controlling the Sessions Between MSDP Peers....................................................................................214
8.5.3 Adjusting the interval for Retrying Setting up an MSDP Peer Connection..........................................214
8.6 Configuring SA Cache....................................................................................................................................215
8.6.2 Configuring the Maximum Number of (S, G) Entries in the Cache......................................................216
8.6.3 Disabling the SA Cache Function.........................................................................................................217
8.7 Configuring the SA Request...........................................................................................................................218
8.7.2 Configuring "Sending SA Request Messages" on the Local switch.....................................................219
8.7.3 (Optional) Configuring the Filtering Rules for Receiving SA Request Messages................................220
8.7.4 Check the Configuration........................................................................................................................221
8.8 Configuring the Filtering Rules for SA Messages..........................................................................................221
8.8.2 Setting Rules for Creating an SA Message...........................................................................................222
8.8.3 Setting Rules for Receiving an SA Message.........................................................................................223
8.8.4 Setting Rules for Forwarding an SA Message.......................................................................................224
8.9 Configuring MSDP Authentication................................................................................................................226
8.9.2 Configuring MSDP MD5 Authentication..............................................................................................227
8.9.3 Configuring MSDP Key-Chain Authentication....................................................................................227
8.10 Maintaining MSDP.......................................................................................................................................229
8.10.1 Clearing Statistics of MSDP Peers......................................................................................................229
8.10.2 Clearing (S, G) Information in SA Cache...........................................................................................229
8.10.3 Monitoring the Running Status of MSDP...........................................................................................230
8.10.4 Debugging MSDP................................................................................................................................230
8.11.1 Example for Configuring Basic MSDP Functions..............................................................................231
9 IPv4 Multicast Routing Management....................................................................................241

9.1 Overview of IPv4 Multicast Routing Management........................................................................................243
Issue 01 (2011-10-26) Huawei Proprietary and Confidential x

9.2 IPv4 Multicast Routing Management Features Supported by the S5700.......................................................243

9.3 Configuring a Static Multicast Route.............................................................................................................245
9.3.2 Configuring a Static Multicast Route....................................................................................................246
9.4 Configuring the Multicast Routing Policy......................................................................................................247
9.4.2 Configuring Longest Match of Multicast Route....................................................................................248
9.4.3 Configuring Multicast Load Splitting....................................................................................................249
9.4.4 Configuring a Multicast Load Splitting Weight....................................................................................249
9.5 Configuring the Multicast Forwarding Scope................................................................................................251
9.5.1 Establish the Configuration Task..........................................................................................................251
9.5.2 Configuring the Multicast Forwarding Boundary.................................................................................251
9.6 Configuring Control Parameters of the Multicast Forwarding Table.............................................................252
9.6.2 Setting the Maximum Number of Entries in Multicast Forwarding Table............................................253
9.6.3 Setting the Maximum Number of Downstream Nodes of Multicast Forwarding Entry.......................254
9.7 Maintaining the Multicast Policy...................................................................................................................255
9.7.1 Testing Multicast Routing.....................................................................................................................255
9.7.2 Check RPF Paths and Multicast Paths...................................................................................................255
9.7.3 Clearing Multicast Routing and Forwarding Entries.............................................................................256
9.7.4 Monitoring the Status of Multicast Routing and Forwarding................................................................257
9.7.5 Debugging Multicast Routing and Forwarding.....................................................................................257
9.8 Configuration Examples.................................................................................................................................258
9.8.1 Example for Changing Static Multicast Routes to RPF Routes............................................................258
10 MLD Snooping Configuration..............................................................................................263

10.1 Overview of MLD Snooping........................................................................................................................265
10.2 MLD Snooping Features Supported by the S5700.......................................................................................265
10.3 Configuring Basic Functions of MLD Snooping.........................................................................................266
10.3.2 Enabling MLD snooping on the S5700...............................................................................................267
10.3.3 Enabling MLD Snooping in a VLAN..................................................................................................267
10.3.4 (Optional) Adding an Interface to a Multicast Group Statically.........................................................268
10.3.5 (Optional) Configuring an Interface as a Static Router Interface........................................................268
10.3.6 (Optional) Setting the Maximum Number of Multicast Groups that Hosts Attached to an Interface Can
Join..................................................................................................................................................................269
10.3.7 (Optional) Configuring the MLD Version...........................................................................................269
10.4 Configuring a Multicast Group Policy for a VLAN.....................................................................................270
Issue 01 (2011-10-26) Huawei Proprietary and Confidential xi


10.4.2 Configuring a Multicast Group Policy................................................................................................271
10.5 Configuring Prompt Leave of Interfaces......................................................................................................272
10.5.2 Configuring Prompt Leave of Interfaces.............................................................................................273
10.6 Configuring the MLD Snooping Querier.....................................................................................................273
10.6.2 Enabling the MLD Snooping Querier.................................................................................................274
10.6.3 Setting the MLD Snooping Query Interval and Response Interval.....................................................275
10.6.4 Setting the Source IPv6 Address of MLD Query Messages...............................................................276
10.7 (Optional) Modifying Parameters of MLD Snooping..................................................................................276
10.7.2 (Optional) Setting the Aging Time of the Router Interface.................................................................278
10.7.3 (Optional) Setting Parameters Related to the Aging Time of Member Interfaces..............................278
10.7.4 (Optional) Configuring the Router Alert Option in MLD Messages..................................................279
10.7.5 (Optional) Enabling the MLD Snooping Module to Respond to Changes of the Layer 2 Network
Topology.........................................................................................................................................................279
10.7.6 (Optional) Setting the Duration for Suppressing the Same MLD Messages.......................................280
10.8 Maintaining MLD Snooping........................................................................................................................281
10.8.1 Clearing MLD Snooping Entries.........................................................................................................281
10.8.2 Clearing the Statistics on MLD Snooping...........................................................................................282
10.8.3 Debugging MLD Snooping.................................................................................................................282
10.9.1 Example for Configuring Prompt Leave of Interfaces in a VLAN.....................................................283
Issue 01 (2011-10-26) Huawei Proprietary and Confidential xii

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
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 S5700
1.3 IPv4 Multicast Configuration Guide
This section describes multicast addresses, protocols, and typical configuration solutions in IPv4
networks.
Issue 01 (2011-10-26) Huawei Proprietary and Confidential 1

1.1 IP Multicast Overview

NOTE
The S5700SI and S5706 do not support L3 Multicast.
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 S5700

In the S5700, IPv4 networks and IPv6 networks can support multicast services, but networks
that run IPv4 simultaneously do not support multicast services.
1.3 IPv4 Multicast Configuration Guide

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.

Class D Address Range Description
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.
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 S5700 Series Ethernet Switches 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 S5700s in the network.
2. Enable PIM-DM on all interfaces of the S5700s.
3. Enable IGMP on the S5700 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.
Perform the following configurations:
1. Enable multicast on all S5700s in the network.
2. Enable PIM-SM on all interfaces of the S5700s.
3. Enable IGMP on the S5700 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.

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 S5700
This section describes IGMP snooping features supported by the S5700.
2.3 Configuring IGMP Snooping
This section describes how to configure IGMP snooping in a VLAN.
2.4 Configuring a Static Multicast MAC Address
This section describes how to configure a static multicast MAC address.
2.5 Configuring Layer 2 Multicast SSM Mapping
This section describes how to configure the Layer 2 multicast SSM mapping function.
2.6 Maintaining Layer 2 Multicast
Maintaining Layer 2 multicast involves resetting Layer 2 Multicast statistics, and debugging
IGMP Snooping.
2.7 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.
IGMP Snooping Function

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. Thus the IGMP snooping protocol manages and controls the forwarding of multicast
packets.
After receiving multicast packets from an upstream device, an Ethernet device at the edge of the
access network forwards the multicast packets to multicast receivers. As shown in Figure 2-1,
multicast data is broadcast at the data link layer by default, which wastes network bandwidth
and causes multicast data to be sent to unpaid subscribers.
If IGMP snooping is configured on the Layer 2 device, multicast data of a known group is
forwarded to specified receivers (paid subscribers) but not broadcast at the data link layer.
Figure 2-1 Comparison before and after IGMP snooping is configured on a Layer 2 device
Multicast packet transmission Multicast packet transmission
without IGMP Snooping when IGMP Snooping runs
Source Source
Router Router
PIM PIM
Switch Switch
Reciever A Reciever B Reciever A Reciever B
Multicast Packet

IGMP Snooping Advantages

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, and thus saving network bandwidth
l Enhancing the security of multicast information
l Performing accounting for each host independently
2.2 IGMP Snooping Supported by the S5700

This section describes IGMP snooping features supported by the S5700.
IGMP Snooping
The S5700 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 S5700 to actively send IGMP Query messages so that the S5700 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 S5700 receives an IGMP Leave message to leave a specified multicast
group, the S5700 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 S5700 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 Proxying

Configuring IGMP snooping proxying 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 proxying 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.
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
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. Thus the IGMP snooping protocol manages and controls the forwarding of multicast
packets.

If IGMP snooping is configured on the Layer 2 device, multicast data of a known group is
forwarded to specified receivers (paid subscribers) but not broadcast at the data link layer.
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
8 (Optional) Source IP address of IGMP Query

messages
2.3.2 Enabling IGMP Snooping
Context
By default, IGMP snooping is disabled on the S5700. You need to enable IGMP snooping on
the S5700 globally.
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.

Procedure
Step 1 Run:
system-view
The system view is displayed.

Step 2 Run:
igmp-snooping enable
IGMP snooping is enabled globally.

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

Step 4 (Optional)Run:
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.
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.
NOTE
The S5700SI does not support this command.
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.
If IGMP snooping is enabled in a VLAN, N:1 VLAN mapping or VLAN stacking cannot be configured.
Step 6 (Optional)Run:
igmp-snooping version { 1 | 2 |3 }
The version of IGMP messages that the S5700 can process is set.
By default, the S5700 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.3 (Optional) Configuring a Static Router Interface
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.
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.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 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.
Step 4 Run:
quit

Step 5 Run:
interface interface-type interface-number
The interface view is displayed.

The interface can be a GE interface, an XGE interface, or an Eth-Trunk interface. It is the
interface that connects the S5700 to the upstream router.
Step 6 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.4 (Optional) Configuring Multicast Group Member Interfaces
Context
Multicast group member interfaces are responsible for receive multicast data sent for multicast
groups or source-specific multicast groups. By default multicast group members interfaces are

dynamic. If a dynamic member interface has not received any IGMP Report messages for a
multicast group before its aging time expires, the device deletes this member interface from the
downstream interface list of the multicast forwarding entry for this group.
If each interface in a VLAN connects only one receiver host, you can enable prompt leave for
interfaces in the VLAN. After prompt leave is enabled and if the device receives an IGMP Leave
from a member interface, the device immediately deletes the forwarding entry related to this
interface from the multicast forwarding table.
If hosts connected to an interface want to steadily receive multicast data for a multicast group
or a source-specific multicast group, statically add the interface to the multicast group or source-
specific multicast group. The interface is then a static member interface and does not age.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Set the aging time of dynamic member interfaces. For details, see 2.3.5 (Optional) Configuring
IGMP Snooping Querier.
If multicast group members frequently change, set the aging time of dynamic member interfaces
to a smaller value.
Step 4 Run:
igmp-snooping prompt-leave [ group-policy acl-number ]
Prompt leave is enabled for interfaces in the VLAN.

By default, prompt leave is disabled for interfaces.
If group-policy acl-number is not specified, the S5700 immediately deletes the forwarding entry
corresponding to a member interface after receiving the Leave message from the interface.
NOTE
On the S5700, 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.
Step 5 Run:
quit
Return to the system view.

Step 6 (Optional) Configuring static member interfaces
1. Run:

The interface can be a GE, Ethernet, or Eth-Trunk interface on the LAN side.
2. (Optional) Run:
undo igmp-snooping learning vlan { vlan-id { [ &<1–10> ][to vlan-id ] | all } }

The interface is disabled from learning forwarding entries.

The interface can be a GE interface, an XGE interface, or an Eth-Trunk interface.
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 a multicast group statically. It is then a static member interface.
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 add the
interface to multiple multicast groups.
NOTE
After an interface is added to a multicast group statically, existing entries cannot be replaced.
----End
2.3.5 (Optional) Configuring IGMP Snooping Querier
Context
If IGMP messages sent from the upstream router cannot reach the S5700 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 S5700. 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.
Step 4 (Optional) Run:
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.

Step 6 Run:
igmp-snooping max-response-time max-response-time
The maximum response time of IGMP Query messages is set.

By default, the maximum response time of IGMP Query messages is 10 seconds.
NOTE
The maximum response time must be shorter than the interval at which IGMP General Query messages
are sent.
After receiving IGMP Report messages from hosts, the S5700 sets the aging time of member interfaces
based on the following formula: IGMP robustness variable x Interval at which IGMP General Query
messages are sent + Maximum response time of IGMP Query messages. If all the parameters are of the
default value, the aging time of member interfaces defaults to 130 seconds.

igmp-snooping lastmember-queryinterval lastmember-queryinterval
The interval at which the querier sends Last Member Query (IGMP Group-Specific Query)
messages is set.
By default, the interval at which IGMP Group-Specific Query messages are sent is 1 second.
NOTE
After receiving IGMP Leave messages from hosts, the S5700 sets the aging time of member interfaces by
using the following formula: Interval at which IGMP Group-Specific Query messages are sent x IGMP
robustness variable.
IGMPv1 hosts do not send Leave messages when leaving multicast groups. Therefore, the igmp-snooping
lastmember-queryinterval command is valid only when the IGMP snooping version is set to 2 in the
VLAN.
----End
2.3.6 (Optional) Setting the Maximum Number of Multicast Groups

that Hosts Attached to an Interface Can Join
Context
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 users can join.
Procedure
Step 1 Run:
system-view

Step 2 Run:


Step 3 Run:
igmp-snooping group-limit group-limit vlan {vlan-id [ to vlan-id ] } &<1-10>
The maximum number of multicast groups that hosts attached to the interface can join.
If vlan-id is specified, the maximum number of multicast groups that hosts attached to the
interface in a specified VLAN can join is set.
----End
2.3.7 (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 S5700 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.8 (Optional) Setting the Suppression Time of IGMP Messages
Context
A Layer 2 device forwards IGMP Report or Leave messages received from multicast group
members to its directly connected Layer 3 device. If the Layer 2 device has multiple attached

hosts belonging to the same multicast group, the Layer 3 device receives duplicated IGMP Report
or Leave messages from these hosts.
After IGMP Report and Leave message suppression is enable, the Layer 2 device sends only the
IGMP Report or Leave message received first for a multicast group to the Layer 3 device in one
query interval and does not send Report or Leave messages received subsequently for this
multicast group, reducing the number of packets transmitted over the network.
During the suppression time, the S5700 sends only one copy of the same IGMP messages
continuously sent by hosts upstream. This reduces the number of redundant messages.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp-snooping report-suppress
IGMP Report and Leave message suppression is enabled.
After IGMP Report and Leave message suppression is enabled, the S5700 sends a Report or
Leave message upstream only when the first host joins a multicast group or the last member
leaves a multicast group.

igmp-snooping suppress-time suppress-time
The suppression time of IGMP messages is set in the VLAN.
By default, the suppression time of IGMP messages is 10 seconds. You are recommended to set
the suppression time of IGMP Report or Leave messages the same as the maximum response
time of IGMP Query messages.
----End
2.3.9 (Optional) Enabling the Discarding of Unknown Multicast

Data Packets in a VLAN
Context
Unknown multicast data packets are broadcast in a VLAN by default. 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. If
multicast services are unstable, for example, users frequently join or leave multicast groups,
unknown multicast data packets need to be processed; otherwise some users cannot receive
multicast data.

Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id

Step 3 Run:
multicast drop-unknown
Discarding unknown multicast data packets is enabled.

By default, unknown multicast data packets are broadcast in the VLAN.
----End
2.3.10 (Optional) Configuring the S5700 to Actively Send IGMP

Query Messages
Context
If a Layer 2 network topology changes, the forwarding path of VLAN packets may change. To
enable the S5700 to rapidly sense the Layer 2 network topology change, configure the S5700 to
actively send IGMP Query messages. The S5700 then updates information about multicast
member interfaces according to the IGMP Report messages and quickly reroutes multicast
packets for the VLAN to new forwarding paths, preventing interruption of multicast services.
Procedure
Step 1 Run:
system-view

Step 2 Run:
igmp-snooping send-query enable
The S5700 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, theS5700 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) Configuring Router Alert Options in IGMP

Messages

Context
Router-Alert is a mechanism used to identify protocol packets. The packets carrying Router-
Alert options are delivered to the routing protocol layer for processing.
By default, devices do not check whether packets carry Router-Alert options for the sake of
compatibility, and send all IGMP messages to the upper layer for processing. To improve device
performance, reduce costs, and ensure protocol security, configure devices to send packets
without Router-Alert options.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp-snooping require-router-alert
The S5700 is configured to receive IGMP messages that must contain the Router Alert option
in the IP header. The S5700 does not process the packet but discard the packet directly.
By default, the S5700 can receive IGMP messages that do not contain the Router Alert options
in the IP headers from a VLAN.
Step 4 Run:
igmp-snooping send-router-alert
The S5700 is configured to contain the Router Alert option in the IP header of the sent IGMP
messages. You can run the undo igmp-snooping send-router-alert command to set the IP
header of the sent IGMP packet not to contain the Router-Alert option.
By default, the S5700 sends IGMP messages that contain the Router Alert options in the IP
headers to a VLAN.
----End
2.3.12 (Optional) Configuring the IGMP Snooping Proxy for the

VLAN
Context
After the IGMP proxy is configured on the S5700, the S5700 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 S5700 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 S5700.
Procedure
Step 1 Run:
system-view

Step 2 Run:

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) GE0/0/1 -D-
1 port(s)
VLAN 102, 1 Entry(s)
(*, 225.0.0.1) GE0/0/24 -D-
1 port(s)
-----------------------------------------------------------------------
<Quidway> display igmp-snooping router-port vlan 3
Port Name UpTime Expires Flags
--------------------------------------------------------------
VLAN 3, 2 router-port(s)
GE0/0/1 1d:22h 00:01:20 DYNAMIC
GE0/0/2 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
<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) GigabitEthernet0/0/1 7
-----------------------------------------------------------------------
Total Group(s) : 1
2.4 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.

NOTE
The S5700SI does not support static multicast MAC addresses.
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
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 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
Follow-up 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.
# 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 GigabitEthernet0/0/1
GigabitEthernet0/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.5 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.5.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.5.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.5.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) GE0/0/2 --M
1 port(s)
(*, 225.1.1.2) GE0/0/2 --M
1 port(s)
(*, 225.1.1.3) GE0/0/2 --M
1 port(s)
-----------------------------------------------------------------------
2.6 Maintaining Layer 2 Multicast

Maintaining Layer 2 multicast involves resetting Layer 2 Multicast statistics, and debugging
IGMP Snooping.
2.6.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:

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.6.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 S5700 receives IGMP Report
messages from the hosts again and the forwarding entries are regenerated on the S5700.
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.6.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.6.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.7 Configuration examples

This section provides several configuration examples of Layer 2 multicast.
2.7.1 Example for Configuring IGMP Snooping
Networking Requirements
As shown in Figure 2-2, GE 0/0/1 of the S5700 is connected to a router on the multicast source
side, and GE 0/0/2 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
GE0/0/1
Switch
GE0/0/2
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 0/0/2 and GE 0/0/1 belong to: VLAN 3
l Static router interface: GE0/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 0/0/1
[Switch-GigabitEthernet0/0/1] port hybrid tagged vlan 3
[Switch-GigabitEthernet0/0/1] quit


[Switch-GigabitEthernet0/0/2] 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 0/0/1 as the static router interface of VLAN 3.

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

[Switch-GigabitEthernet0/0/2] 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 S5700.
[Switch] display igmp-snooping router-port vlan 3
Port Name UpTime Expires Flags
---------------------------------------------------------------------
VLAN 3, 1 router-port(s)
GE0/0/1 2d:10h -- STATIC
According to the preceding information, GE 0/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) GE0/0/2 S--
1 port(s)
(*, 225.1.1.2) GE0/0/2 S--
1 port(s)
(*, 225.1.1.3) GE0/0/2 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
VLAN ID : 3, Forwarding Mode : IP

--------------------------------------------------------------------
(Source, Group) Interface Out-Vlan
--------------------------------------------------------------------
Router-port GigabitEthernet0/0/1 3
(*, 225.1.1.1) GigabitEthernet0/0/1 3
GigabitEthernet0/0/2 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 S5700
#
sysname Switch
#
vlan batch 3
#
#
vlan 3
#
interface GigabitEthernet0/0/1
port hybrid tagged vlan 3
igmp-snooping static-router-port vlan 3
#
l2-multicast static-group group-address 225.1.1.1 to 225.1.1.3 vlan 3
#
return
2.7.2 Example for Configuring IGMP Snooping SSM Mapping
On the network shown in Figure 2-3, 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
S5700 device. GE 0/0/1 on Switch A is connected to Router A and GE 0/0/2 on Switch A is
connected to a switch directly connected with users. GE 0/0/1 on Switch A is a static router
interface and GE 0/0/2 is statically added to multicast group 224.1.1.1. GE 0/0/1 and GE 0/0/2
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-3 Networking diagram for configuring IGMP snooping SSM mapping
Source 2
10.1.1.2
Internet/
Source 1 Intranet
10.1.1.1
RouterA
GE0/0/1 Swtich
GE0/0/2
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 0/0/1 and GE 0/0/2 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
Procedure
Step 1 Configure a VLAN.
# Configure Switch A.
<Quidway> system-view
[Quidway] sysname SwitchA

[SwitchA] vlan 10
[SwitchA-vlan10] quit
[SwitchA] interface gigabitethernet 0/0/1
[SwitchA-GigabitEthernet0/0/1] port hybrid pvid vlan 10
[SwitchA-GigabitEthernet0/0/1] port hybrid untagged vlan 10
[SwitchA-GigabitEthernet0/0/1] quit
Step 2 Enable global IGMP snooping and IGMP snooping in the VLAN.
# Configure Switch A.
[SwitchA] igmp-snooping enable
[SwitchA] vlan 10
[SwitchA-vlan10] igmp-snooping enable
Step 3 Configure IGMPv3 on Switch A and configure IGMPv2 on hosts. The hosts are not allowed to
upgrade the IGMP version to 3.
# Configure SwitchA.
[SwitchA-vlan10] igmp-snooping version 3
Step 4 Configure GE 0/0/1 as a static router interface in VLAN 10.

[SwitchA-GigabitEthernet0/0/1] 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) GE0/0/2 --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
#
#
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 S5700
This section describes the multicast VLAN replication features supported by the S5700.
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 Configuring Many-to-Many Multicast VLAN Replication
This section describes how to bind multiple user VLANs to multiple multicast VLANs.
3.6 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 S5700

This section describes the multicast VLAN replication features supported by the S5700.
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
The S5700 supports the following mapping modes between multicast VLANs and user VLANs:
l One-to-many mapping between a multicast VLAN and user VLANs
l Many-to-many mapping between multicast VLANs and 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 S5700 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
l Enabling IGMP snooping globally
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
A VLAN is created and the VLAN view is displayed.

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 S5700, 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
l Enabling IGMP snooping globally
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
A VLAN is created and the VLAN view is displayed.

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.
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
------------------------------------------------------------------
GigabitEthernet0/0/1 901 -- 90
Total Table(s) : 1
3.5 Configuring Many-to-Many Multicast VLAN

Replication
This section describes how to bind multiple user VLANs to multiple multicast VLANs.

In many-to-one mode, a user VLAN can be added to only one multicast VLAN and users in the
user VLAN can receive programs of only one multicast group. Many-to-many multicast VLAN
allows you to add a user VLAN to multiple multicast VLANs and specify multiple multicast
groups for users in the user VLAN.
When a user VLAN needs to be mapped to multiple multicast VLANs, enable the user VLAN
to be added to multiple multicast VLANs, and configure multicast flows.
Before configuring the many-to-many multicast VLANs, complete the following tasks:
l Connecting interfaces of Switch and setting physical parameters for the interfaces to ensure
that the physical status of the interfaces is Up.
l Adding interfaces to the multicast VLAN and user VLAN.
Data Preparation
To configure many-to-many multicast VLANs, you need the following data.
Number Data
1 Multicast VLAN IDs
2 User VLAN ID
3 Type and number of an interface
4 Multicast group address of the static flow in

multicast VLANs
3.5.2 Enabling a User VLAN to Be Added to Multiple Multicast

VLANs
Prerequisite
Before adding a user VLAN to multiple multicast VLANs, run the multicast flow-trigger
enable command.
Procedure
Step 1 Run:
system-view
Step 2 Run:

IGMP snooping is enabled globally.
Step 3 Run:
vlan vlan-id
A user VLAN is created and its view is displayed.
Step 4 Run:
IGMP snooping is enabled in the user VLAN.
Step 5 Run:
multicast flow-trigger enable
The user VLAN is enabled to be added to multiple multicast VLANs.
The multicast flow-trigger enable command can only be used in user VLANs.
----End
3.5.3 Adding a User VLAN to Multiple Multicast VLANs
Prerequisite
If a user in a user VLAN wants to receive multicast data in multiple multicast VLANs, repeat
the following steps to add the user VLAN to multiple multicast VLANs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
A VLAN is created and its view is displayed.
Step 3 Run:
Step 4 Run:
Multicast VLAN replication is enabled and the current VLAN is configured as a multicast
VLAN.
After IP multicast is configured on the S5700, no multicast VLAN can be configured.
Step 5 Run:
multicast-vlan user-vlan { { vlan-id1 [ to vlan-id2 ] } & <1-10> }
User VLANs are added to the multicast VLAN.

Before adding the user VLAN to multiple multicast VLANs, run the multicast flow-trigger
enable command in the user VLAN view to enable it to be added to multiple multicast VLANs.
----End
3.5.4 (Optional) Configuring a Static Flow in a Multicast VLAN
Context
When user VLANs need to join multiple multicast VLANs, you need to run the multicast flow-
trigger enable command in the view of each user VLAN to enable the triggering of multicast
flows, and then configure static flows in each multicast VLAN. In this manner, the many-to-
many mapping based on {UVLAN, Source, Group} is set up between user VLANs and multicast
VLANs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
The IGMP snooping is enabled.
Step 4 Run:
The multicast VLAN is enabled.
Step 5 Run:
multicast static-flow { ipv4-group-address [ source ipv4–source-address ] | ipv6
ipv6-group-address [ source ipv6–source-address ] }
A static flow is configured in a multicast VLAN.
By default, no static flow is configured in a multicast VLAN.
NOTE
Any two static flows in a multicast VLAN cannot be the same. Note that flows of the same multicast group
with different source IP addresses are considered as different flows.
----End

Procedure
l Run the display multicast static-flow [ mvlan vlan-id ] command to view the static flow
in a multicast VLAN.
----End
Example
# Run the display multicast static-flow [ mvlan vlan-id ] command to view the static flow in
multicast VLAN 10.
<Quidway> display multicast static-flow
-------------------------------------------------------------------
Vlan (Source, Group)
-------------------------------------------------------------------
10 (*, 225.1.1.1)
-------------------------------------------------------------------
Total Table(s) : 1

This section provides configuration examples of multicast VLAN replication.
3.6.1 Example for Configuring Multicast VLAN Replication Based

on User VLANs
As shown in Figure 3-4, RouterA is connected to the multicast source. GE 1/0/0 of RouterA is
connected to GE0/0/1 of SwitchA. GE0/0/1 of SwitchA belongs to VLAN 10. HostA, HostB,
and HostC are connected to GE0/0/2, GE0/0/3, and GE0/0/4 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
GE0/0/1 SwitchA
GE0/0/2 GE0/0/4
GE0/0/3
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 and enable IGMP snooping in the 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.
<SwitchA> system-view
Step 2 Create a multicast VLAN and enable IGMP snooping in the multicast VLAN.

[SwitchA] vlan 10
[SwitchA-vlan10] 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.
[SwitchA] vlan 10
[SwitchA-vlan10] multicast-vlan user-vlan 100 200 300
Step 5 Add interfaces to VLANs as hybrid interfaces.

# Add GE0/0/1 to multicast VLAN 10.
[SwitchA] interface gigabitethernet0/0/1
# Add GE0/0/2, GE0/0/3, and GE0/0/4 to user VLANs 100, 200, and 300 respectively.

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
-----------------------------------------------------------------------------
----End
Configuration Files
l Configuration file of SwitchA

#
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.6.2 Example for Configuring Multicast VLAN Replication Based

on Interfaces
As shown in Figure 3-5, the Router is connected to the multicast source. GE 0/0/1 of the Switch
A is connected to the Router. GE 0/0/2 provides services for ISP1, and GE 0/0/3 provides services
for ISP2. ISP1 and ISP2 use multicast VLAN 2 and VLAN 3 respectively to provide multicast
services for users. GE 0/0/2 and GE 0/0/3 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
GE0/0/1
GE0/02
GE0/0/3
SwitchA
ISP1 ISP2
VLAN10 VLAN10
Receiver Receiver
HostA HostB
Multicast Packet
Multicast VLAN 2
Multicast VLAN 3
1. Enable IGMP snooping globally.
2. Create multicast VLANs 2 and 3 and enable IGMP snooping in the multicast VLANs.
3. Create user VLAN 10.
4. Bind the user VLAN to multicast VLANs on GE 0/0/2 and GE 0/0/3.
5. 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.

[Switch] vlan batch 10
Step 3 Bind the user VLAN to multicast VLANs on GE 0/0/2 and GE 0/0/3.
[SwitchA-GigabitEthernet0/0/2] l2-multicast-bind vlan 10 mvlan 2
[SwitchA-GigabitEthernet0/0/3] l2-multicast-bind vlan 10 mvlan 3
Step 4 Add GE0/0/1 to the multicast VLANs, and add GE 0/0/2 and GE 0/0/3 to the user VLAN.
# Add GE0/0/1 to multicast VLANs 2 and 3 as a trunk interface.
[SwitchA-GigabitEthernet0/0/1] port link-type trunk
[SwitchA-GigabitEthernet0/0/1] port trunk allow-pass vlan 2 3
# Add GE0/0/2 and GE0/0/3 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
-------------------------------------------------------------------
Port Startvlan Endvlan Mvlan
-------------------------------------------------------------------
-------------------------------------------------------------------
Total Table(s) : 2
----End
Configuration Files
l Configuration file of the SwitchA
#
sysname Switch
#
vlan batch 2 3 10
#
#
vlan 2
#
vlan 3

#
port link-type trunk
port trunk allow-pass vlan 2 3
#
l2-multicast-bind vlan 10 mvlan 2
#
l2-multicast-bind vlan 10 mvlan 3
#
return
3.6.3 Example for Configuring Many-to-Many Multicast VLANs
As shown in Figure 3-6, GE 0/0/1 of Switch is connected to Router A and receives multicast
data from Router A through multicast VLAN 10.GE 0/0/2 of Switch is connected to Router B
and receives multicast data from Router B through multicast VLAN 20. GE 0/0/3 of Switch is
connected to the user VLAN.
The user needs to receive data of multicast group 225.1.1.1 from Router A and receive data of
multicast group 225.1.2.1 from Router B.
Figure 3-6 Networking diagram of many-to-many multicast VLAN replication based on user
VLANs
RouterA RouterB
S1 S2
MVLAN10 MVLAN20
GE0/0/2 GE0/0/1
GE0/0/3 Switch
UVLAN100
Receiver

1. Enable IGMP snooping in the system view.

2. Create multicast VLANs and enable IGMP snooping in the multicast VLAN.
3. Create a user VLAN and enable IGMP snooping in the user VLAN. Enable the triggering
of the multicast flow in the user VLAN.
4. Add the user VLAN to multiple multicast VLANs and configure the static multicast flow
in the multicast VLANs.
5. Add the network-side interfaces and user-side interface to VLANs as hybrid interfaces.
Data Preparation
l Interfaces connected to the routers and the multicast VLANs that the interfaces belong to
l Interfaces connected to the user and the multicast VLANs that the interfaces belong to
Procedure
Step 1 Enable IGMP snooping in the system view.
Step 2 Create multicast VLANs 10 and 20 and enable IGMP snooping in the multicast VLANs.
[Switch] vlan 10
[Switch-vlan10] multicast-vlan enable
[Switch-vlan10] quit
[Switch] vlan 20
[Switch-vlan20] multicast-vlan enable
Step 3 Create user VLAN 100 and enable IGMP snooping in the user VLAN. Enable the triggering of
the multicast flow in the user VLAN.
[Switch] vlan 100
[Switch-vlan100] multicast flow-trigger enable
Step 4 Add user VLAN 100 to multicast VLANs10 and 20 and configure the static multicast flow in
the multicast VLANs.
[Switch] vlan 10
[Switch-vlan10] multicast-vlan user-vlan 100
[Switch-vlan10] multicast static-flow 225.1.1.1
[Switch] vlan 20
[Switch-vlan20] multicast-vlan user-vlan 100
[Switch-vlan20] multicast static-flow 225.1.2.1
Step 5 Add interfaces to VLANs as hybrid interfaces.

# Add GE 0/0/1 to multicast VLAN 20. Add GE 0/0/2 to multicast VLAN 10.
[Switch-GigabitEthernet0/0/1] port hybrid pvid vlan 20
[Switch-GigabitEthernet0/0/1] port hybrid untagged vlan 20


# Add GE 0/0/3 to user VLAN 100.


# Run the display user-vlan vlan command. You can see that the user VLAN has been added
to multicast VLANs 10 and 20.
[Quidway] display user-vlan vlan
Total user vlan 2
-----------------------------------------------------------------------------
# Run the display multicast static-flow command to view the static multicast flow in the
multicast VLANs. Users in the user VLAN can be added to the multicast group.
[Quidway] display multicast static-flow
-------------------------------------------------------------------
Vlan (Source, Group)
-------------------------------------------------------------------
10 (*, 225.1.1.1)
20 (*, 225.1.2.1)
-------------------------------------------------------------------
Total Table(s) : 2
----End
Configuration File
l Configuration file of the Switch
#
sysname Switch
#
vlan batch 10 20 100
#
#
vlan 10
igmp-snooping
enable
multicast-vlan
enable
multicast static-flow 225.1.1.1
multicast-vlan user-vlan 100
#
vlan 20
igmp-snooping
enable
multicast-vlan
enable
multicast static-flow 225.1.2.1
multicast-vlan user-vlan 100
#
vlan 100
multicast flow-trigger enable
#


#
#
#
return

Configuration Guide - Multicast 4 Controllable Multicast Configuration
4 Controllable Multicast Configuration
About This Chapter
This chapter describes the principle of controllable multicast and procedures for configuring
controllable multicast.
4.1 Overview of Controllable Multicast

4.2 Basic Principle
4.3 Configuring Controllable Multicast
This section describes how to configure controllable multicast.
4.4 Configuration Example
This section provides configuration examples of controllable multicast.

4.1 Overview of Controllable Multicast

Traditional multicast services are uncontrollable. Users running traditional multicast need to
send IGMP Report messages to join related multicast groups, and then receive multicast packets
of the groups. With the development of IPTV services, uncontrollable multicast services cannot
meet the operation requirements. IPTV services aim to make prohibits. Users can watch a
program (that is, join a multicast group) only after they pay fees. If users are not authenticated,
the requirements of IPTV operation cannot be met. Therefore, controllable multicast is
developed to control the authorities of users to join a certain multicast group. When a user
requests to join a multicast group, the Switch must authenticate the request, and reject illegal or
unauthorized requests.
4.2 Basic Principle
Controllable Multicast Mechanism Provided by the S-switch

The S5700 provides the controllable multicast mechanism based on VLANs. Through multicast
profiles, the S5700 controls the authorities of users to join related multicast groups. To flexibly
configure the rights of users to join related multicast groups, the S5700 provides control
mechanisms of three levels, that is, multicast group, multicast group list, and multicast profile,
as shown in Figure 4-1.
Figure 4-1 Hierarchical control mechanisms of controllable multicast

Multicast Group Multicast Group G1
List L1
Multicast Multicast Group G2
Profile P1
Multicast Group G3
Multicast Group Multicast Group G4

List L2
Multicast Multicast Group G5

Profile P2
Multicast Group
List L1 Multicast Group GN
Multicast Group
A multicast group corresponds to a multicast address such as 224.1.1.1. A multicast group can
be regarded as a channel or program of IPTV.
Multicast Group List

A multicast group list is a set of multicast groups. A multicast group list can contain several
multicast groups. For example, in Figure 4-1, multicast group list L1 contains G1, G2, G3, and

G4. A multicast group can be contained in several multicast group lists. For example, G3 is
contained in L1 and L2.
Multicast Profile
A multicast profile is a set of multicast group lists, and defines the frame of users' rights to join
related multicast groups. A multicast profile can contain several multicast group lists. For
example, in Figure 4-1, multicast profile P1 contains L1, L2, and L3. A multicast group list can
be contained in several multicast profiles. For example, L2 is contained in P1 and P2. Multicast
group lists that are added to a profile have their attributes, that is, preview and watch. If a
multicast group list is added to a multicast profile in watch mode, users of the multicast profile
can watch all multicast groups in the list. If a multicast group list is added to a multicast profile
in preview mode, users of the multicast profile can preview all multicast groups in the list.
Control Flow
The S5700 on which controllable multicast is applied can control the generation of Layer 2
multicast forwarding entries by intercepting IGMP Report messages. After receiving an IGMP
Report message from a user, the S5700 obtains the profile based on the VLAN to which the
message belongs. If the group is not in the list of the profile, the user cannot join the group. The
S5700 intercepts the IGMP Report message and do not generate the related forwarding entry.
Therefore, the user cannot receive data flows of this group. If the multicast group is in the list
of the profile, check the mode through which the list is added to the profile. If the list is added
to the profile in watch mode, the S5700 allows the IGMP Report message to pass through. If the
list is added to the profile in preview mode, the S5700 allows the IGMP Report message to pass
through and starts a timer at the same time. When the preview period expires, the S5700 deletes
the forwarding entry of the group and intercepts subsequent IGMP Report messages of the group.
The preview function is implemented.
4.3 Configuring Controllable Multicast

This section describes how to configure controllable multicast.

To control the authorities of users to join related multicast groups, you can configure controllable
multicast.
Before configuring controllable multicast, complete the following task:
l Configuring Layer 2 multicast, that is, IGMP snooping or IGMP proxy, to forward multicast
packets normally
NOTE
In the multicast VLAN, controllable multicast needs to be configured in the user VLAN.
Data Preparation
To configure controllable multicast, you need the following data.

No. Data
1 Name and IP address of a multicast group
2 Name of a multicast list
3 Name of a multicast profile
4 IDs of the user VLANs that apply multicast profiles
4.3.2 Configuring a Multicast Group
Procedure
Step 1 Run:
system-view
Step 2 Run:
btv
The BTV view is displayed.
Step 3 Run:
multicast-group group-name { ip-address multicast-group-address [ source ipv4-
source-address ] | ipv6-address mld-group-address [ source ipv6-source-address ] }
A multicast group is configured.
By default, no multicast group is configured on the S5700.
NOTE
If the interface connected to the user device is configured IGMPv2, you do not need to specify the
source ipv4-source-address parameter; if the interface is configured with IGMPv3, you must specify
source ipv4-source-address.
If the configured multicast groups have the same address, you can use the group-name parameter to change
the names of multicast groups.
----End
4.3.3 Configuring a Multicast Group List
Procedure
Step 1 Run:
system-view
Step 2 Run:
btv


Step 3 Run:
multicast-list list-name
A multicast group list is created and the view of the multicast group list is displayed.
Step 4 Run:
add multicast-group { name group-name | index start-index to end-index }
A multicast group is added to the multicast group list.

By default, no multicast group list is configured on the S5700.
----End
4.3.4 Configuring a Multicast Profile
Procedure
Step 1 Run:
system-view

Step 2 Run:
btv

Step 3 Run:
multicast-profile profile-name
A multicast profile is created and the view of the multicast profile is displayed.
Step 4 Run:
add multicast-list { name list-name | index start-index to end-index } { watch |
preview }
A multicast group list is added to the multicast profile.

By default, no multicast profile is configured on the S5700.
Step 5 Run:
max-program-num max-value
The maximum number is configured for multicast groups that users in the multicast profile can
simultaneously join.
NOTE
On the S5700, users in a multicast profile can simultaneously join a maximum of eight multicast groups.
This is also the default setting.
Step 6 Run:
multicast-preview interval interval
Set the interval between the first and second previews on a multicast group.
Step 7 Run:

multicast-preview minutes minutes
Set the period for a user to preview a multicast group each time.
Step 8 Run:
multicast-preview times times
Set the number of times for a user to preview a multicast group each day.
----End
4.3.5 Applying a Multicast Profile to a VLAN
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
attach multicast-profile profile-name [ interface interface-type interface-number
| mac-address mac-address ] *
The binding relationship is set between the VLAN and the multicast profile.
By default, the binding relationship between the VLAN and the multicast profile is not set in
S5700.
Multiple multicast profiles can be bound to users in a VLAN.
NOTE
The S5700 supports the port+VLAN multicast control mode. To configure the multicast service for multiple
user interfaces in the same VLAN, you need to specify a multicast profile for each interface individually
by specifying the interface interface-type interface-number parameter.
----End
Procedure
Step 1 Run the display multicast-group [ group-name ] command to check information about a
multicast group.
Step 2 Run the display multicast-list [ list-name ] command to check information about a multicast
group list.
Step 3 Run the display multicast-profile [ profile-name [ verbose ] ] command to check information
about a multicast profile.

Step 4 Run the display multicast-profile-apply command to information about a VLAN where a
multicast profile is applied.
----End

This section provides configuration examples of controllable multicast.
4.4.1 Example for Configuring Controllable Multicast
As shown in Figure 4-2, multicast group G1 (225.0.0.1), G2 (225.0.0.2), G3 (225.0.0.3), and
G4 (225.0.0.4) exist in the network connected to the router. You are required to configure users
in VLAN 1 and VLAN 2 to watch G1 and G2,and users in VLAN 3 and VLAN 4 to watch all
multicast groups.
Figure 4-2 Networking diagram of configuring controllable multicast

G1(10.1.1.1,225.0.0.1) G3(12.1.1.1,225.0.0.1)
Network
G2(11.1.1.1,225.0.0.1) G4(13.1.1.1,225.0.0.1)
Switch
VLAN1 VLAN2 VLAN3 VLAN4

l Configure user VLANs.

l Configure IGMP snooping.
l Configure controllable multicast.
– Two multicast group lists L1 (G1, G2) and L2 (G3, G4)
– Two multicast profiles P1 and P2
Data Preparation
1. Name of each multicast group
2. Name of each multicast group list
3. Name of each multicast profile
Configuration Procedure
1. Configure user VLANs and add the interface to the user VLANs. The configuration details
are not provided here.
2. Configure IGMP snooping.
[Switch] vlan 1
[Switch-vlan1] quit
[Switch] vlan 2
[Switch-vlan2] quit
[Switch] vlan 3
[Switch-vlan3] quit
[Switch] vlan 4
[Switch-vlan4] quit
3. Configure controllable multicast.

# Configure multicast groups.
[Switch] btv
[Switch-btv] multicast-group G1 ip-address 225.0.0.1
# Configure multicast group lists.

[Switch-btv] multicast-list L1
[Switch-btv-list-L1] add multicast-group name G1
[Switch-btv-list-L1] quit
[Switch-btv] multicast-list L2
[Switch-btv-list-L2] quit
# Configure multicast profiles.

[Switch-btv] multicast-profile P1
[Switch-btv-profile-P1] add multicast-list name L1 watch
[Switch-btv-profile-P1] quit
[Switch-btv] multicast-profile P2
[Quidway-btv-profile-P2] quit
[Quidway-btv] quit

# Apply multicast profiles to VLANs.

[Switch] vlan 1
[Switch-vlan1] attach multicast-profile P1
[Switch-vlan1] quit
[Switch] vlan 2
[Switch-vlan2] quit
[Switch] vlan 3
[Switch-vlan3] quit
[Switch] vlan 4
[Switch-vlan4] quit
# Verify the configuration.

[Switch-btv] display multicast-profile-apply
------------------------------------------------------------------------------
Vlan-id Port SMAC Max-User Index Profile-
name
------------------------------------------------------------------------------
Vlan1 -- -- 8 1 P1
Vlan2 -- -- 8 1 P1
Vlan3 -- -- 8 2 P2
Vlan4 -- -- 8 2 P2
Total: 4
[Switch-btv] display multicast-profile
-----------------------------------------------------------------------------
Index Profile-Name Multicast-list Attach-

User
-----------------------------------------------------------------------------
1 P1 1 2
2 P2 2 2
Total: 2
[Switch-btv] display multicast-list
-------------------------------------------------------------------------
Index Multicast-list-name Multicast-
group
-------------------------------------------------------------------------
1 L1
2
2 L2
2
Total: 2
[Switch-btv] display multicast-group

-------------------------------------------------------------------------
Index Multicast-group-name
Address
-------------------------------------------------------------------------
1 G1 225.0.0.1
2 G2 225.0.0.2
3 G3 225.0.0.3
4 G4 225.0.0.4
Total: 4

Configuration Files
sysname Switch
#
vlan batch 1 to 4
#
#
#
btv
multicast-group G1 ip-address 225.0.0.1
#
multicast-list L1
add multicast-group name G1
multicast-list L2
#
multicast-profile P1
add multicast-list name L1 watch
multicast-profile P2
#
vlan 1
attach multicast-profile P1
#
vlan 2
#
vlan 3
#
vlan 4
#
return

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

This section describes the principle of IGMP.
5.2 IGMP Features Supported by the S5700
This section describes IGMP features supported by the S5700.
5.3 Configuring Basic IGMP Functions
This section describes how to configure and apply IGMP.
5.4 Setting the Parameters of IGMP Features
This section describes how to set the parameters of IGMP features.
5.5 Configuring SSM Mapping
This section describes the applications of SSM mapping and the method of configuring SSM
mapping.
5.6 Maintaining IGMP
This section describes how to maintain IGMP.
This section provides several configuration examples of IGMP.

5.1 Introduction to IGMP

This section describes the principle of IGMP.
NOTE
The S5700SI and S5706 do not support 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 S5700 supports IP multicast. When IGMP is configured, the S5700 can
be used as a multicast switch. IGMP is the signaling mechanism of the host towards the
S5700, which is used by IP multicast in an end user network. IGMP needs to be enabled on hosts
and on S5700s.
NOTE
l Whether the host supports IGMP depends on the used operating system.
l The switch mentioned in the following contents is an S5700 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.
5.2 IGMP Features Supported by the S5700

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

The basic IGMP features that the S5700 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 S5700 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
S5700 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 S5700 can serve hosts of IGMPv1 and IGMPv2 after you configure SSM-Mapping on the
S5700.
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 S5700.
– 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
S5700, 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.
5.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 S5700. IGMP needs
to run on both the S5700 and the host. The following contents describe how to configure IGMP
on an S5700.
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 S5700 and host because the IGMP messages vary
according to version. The later version on the S5700 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 S5700. If the host
gives no response and the operation times out, the S5700 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
5.3.2 Enabling IP Multicast
Context
The IP multicast function is the prerequisite of configuring other multicast protocols. Do as
follows on the S5700 connected to a host.
Procedure
Step 1 Run:
system-view

Step 2 Run:
multicast routing-enable
IP multicast routing is enabled.

By default, the IP multicast routing function is disabled on an S5700
----End
5.3.3 Enabling the IGMP Function
Procedure
Step 1 Run:
system-view

Step 2 Run:

On the S5700, VLANIF 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
5.3.4 (Optional) Specifying the IGMP Version
Context
CAUTION
Make sure that all the interfaces on S5700s 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 S5700 uses this interface to communicate with hosts. On the S5700, VLANIF interfaces
and loopback interfaces support IGMP.
Step 3 Run:
igmp version { 1 | 2 | 3 }
The IGMP version is specified on the interface.
----End
5.3.5 (Optional) Configuring a Static IGMP Group
Context
After an interface is added to a multicast group statically, the S5700 considers that multicast
group members exist on the network segment that the interface belongs to. Therefore, S5700
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 S5700 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
S5700 forwards the received data directly.
If a loopback interface is used, the S5700 forwards the received data only when a user requests
the data. This reduces the CPU usage. VLANIF interfaces forward multicast data immediately.
By default, an interface is not statically added to any multicast group.
----End
5.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 [ 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
5.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 S5700, 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 S5700 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 5.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
5.4.2 Configuring IGMP Message Options
Context
The Router-Alert option requires the S5700 to send the received IGMP messages that have not
been added to IGMP groups to the upper layer protocol. By default, the S5700 sends IGMP
messages containing the Router-Alert option, but does not check the Router-Alert option in the
received messages. That is, the S5700 processes all the received IGMP messages, regardless
whether the messages contain the Router-Alert option. If require-router-alert is configured,
the S5700 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 S5700 is configured to ignore the IGMP messages that do not contain the Router-
Alert option.
4. Run:
send-router-alert
The S5700 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 S5700 uses this interface to communicate with hosts. On the S5700, VLANIF
interfaces and loopback interfaces support IGMP.
3. Run:
igmp require-router-alert
The S5700 is configured to ignore the IGMP messages that do not contain the Router-
Alert option.
4. Run:
igmp send-router-alert
The S5700 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
5.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 S5700 starts, the S5700 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:
3. Run:
igmp timer query interval

4. Run:
igmp robust-count robust-value

When the S5700 starts, the S5700 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
5.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:
timer query interval

4. Run:
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

General Query messages is 1/4 of the interval for sending IGMP General Query
messages.
– When receiving a Leave message, the S5700 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 S5700 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:
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 S5700 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 S5700 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
5.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 S5700 leaves the group immediately without sending the Last Member Query message.
By default, the S5700 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 S5700 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
5.5 Configuring SSM Mapping

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 S5700s.
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 5.3.3 Enabling the IGMP Function
Data Preparation
To configure SSM mapping, you need the following data.
No. Data
1 Interface that needs to be enabled with SSM

mapping
2 Addresses and masks of the multicast group

and multicast source

5.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 S5700 interface.
Step 5 Run:
igmp ssm-mapping enable
SSM mapping is enabled.
----End
5.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
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
5.6 Maintaining IGMP

This section describes how to maintain IGMP.
5.6.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
5.6.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
5.6.3 Debugging IGMP

Context
CAUTION
all command to disable it immediately.
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.
5.7.1 Example for Configuring Basic IGMP Functions
On the network as shown in Figure 5-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 0/0/1 on the Switch A to the multicast group 225.1.1.1 statically.

Figure 5-1 Networking diagram for configuring basic IGMP functions
Ethernet
HostA
SwitchA
Receiver
GE0/0/2 GE0/0/1 N1
HostB
SwitchB
Leaf
GE0/0/1
GE0/0/2 network
PIM Network HostC

SwitchC Receiver
GE0/0/1 N2
GE0/0/2 HostD
Ethernet
Switch Physical interface VLANIF interface IP address

Switch A GE 0/0/1 VLANIF 10 10.110.1.1/24
GE 0/0/2 VLANIF 11 192.168.1.1/24
Switch B GE 0/0/1 VLANIF 20 10.110.2.1/24
GE 0/0/2 VLANIF 21 192.168.2.1/24
Switch C GE 0/0/1 VLANIF 30 10.110.3.1/24
GE 0/0/2 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 switch 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 5-1. Configure OSPF
to ensure the communication between Switch A, Switch B, and Switch C 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 Configuring IP Addresses for
Interfaces in the Quidway S5700 Series Ethernet Switches Configuration Guide - Basic
Configurations. For details on how to configure OSPF, see OSPF Configuration in the Quidway
S5700 Series Ethernet Switches Configuration Guide - IP Routing.
Step 2 Enable multicast on all switches and PIM-SM on all interfaces.
# Enable multicast on S5700A and enable PIM-SM on all interfaces. The configurations of
Switch B and Switch C are similar to the configuration of Switch A, 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 Switch A and configure the IGMP version as IGMPv2. The
configurations of Switch B and Switch C are similar to the configuration of Switch A, 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 Switch A 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 Switch
A is as follows:
[SwitchA] display igmp interface vlanif 10
Vlanif 10(10.110.1.1):
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: 0 s
Value of maximum query response time for IGMP: 10 s
Querier for IGMP: 10.110.1.1 (this router)
# Run the display igmp routing-table command on Switch A. 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 Switch

A, 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
#
#
#
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 Switch B

#
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 Switch C

#
sysname SwitchC
#
vlan batch 30 31
#
#
interface Vlanif30
ip address 10.110.3.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.3.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
5.7.2 Example for Configuring SSM Mapping
On the multicast network as shown in Figure 5-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 5-2 Networking of the SSM mapping configuration
S2 S3
133.133.2.1/24 SwitchB SwitchC 133.133.3.1/24
GE0/0/1 GE0/0/3 GE0/0/3 GE0/0/1
GE0/0/2 GE0/0/2
PIM-SM
S1 Receiver
133.133.1.1/24 GE0/0/2 GE0/0/2 133.133.4.1/24
GE0/0/1 GE0/0/1
GE0/0/3 GE0/0/3
SwitchA SwitchD
Switch Physical interfaces VLANIF interface IP address

Switch A GE0/0/1 VLANIF 10 133.133.1.2/24
GE0/0/2 VLANIF 20 192.168.1.1/24
GE0/0/3 VLANIF 30 192.168.4.2/24
Switch B GE0/0/1 VLANIF 11 133.133.2.2/24
GE0/0/2 VLANIF 20 192.168.1.2/24
GE0/0/3 VLANIF 31 192.168.2.1/24
Switch C GE0/0/1 VLANIF 12 133.133.3.2/24
GE0/0/2 VLANIF 21 192.168.3.1/24
GE0/0/3 VLANIF 31 192.168.2.2/24
Switch D GE0/0/1 VLANIF 13 133.133.4.2/24
GE0/0/2 VLANIF 21 192.168.3.2/24
GE0/0/3 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
5-2.
Step 3 Enable IGMP and SSM mapping on the interfaces connected to hosts.
[SwitchD] multicast routing-enable
[SwitchD] interface vlanif 13
[SwitchD-Vlanif13] igmp enable
[SwitchD-Vlanif13] igmp version 3
[SwitchD-Vlanif13] igmp ssm-mapping enable
[SwitchD-Vlanif13] 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
Switch B, SwitchC, and Switch D are similar to configuration of Switch A, and are not provided
here.
[SwitchA-Acl-Basic-2000] rule permit source 232.1.1.0 0.0.0.255
[SwitchA-Acl-Basic-2000] quit
[SwitchA] pim
[SwitchA-pim] ssm-policy 2000
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
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 Switch D 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-queryCounter: 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 Switch D 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-ssm, Flag:EXT NIIF
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-ssm, Flag:EXT NIIF
UpTime: 00:11:25
Downstream interface(s) information:
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 Switch D
#
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 Vlanif21
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface Vlanif30
ip address 192.168.4.1 255.255.255.0
pim sm
#
#
#
#
ospf 1
area 0.0.0.0
network 133.133.4.0 0.0.0.255
network 192.168.3.0 0.0.0.255

network 192.168.4.0 0.0.0.255

#
pim
c-Bsr vlanif30
c-rp vlanif30
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

Configuration Guide - Multicast 6 PIM-DM (IPv4) Configuration
6 PIM-DM (IPv4) Configuration
About This Chapter
The PIM protocol is used 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.
6.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.
6.2 PIM-DM Features Supported by the S5700
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.
6.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.
6.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.
6.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.
6.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.
6.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.
6.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.
6.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.
6.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.
6.11 Maintaining PIM-DM (IPv4)
Maintaining PIM-DM involves resetting PIM statistics, and monitoring PIM running status.
Configuration examples are provided to show how to construct a basic PIM-DM network.

6.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.
CAUTION
This chapter is concerned only about the PIM-DM configuration in an IPv4 network.
NOTE
The S5700SI and S5706 do not support IPv4 PIM.
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 6-1.
Figure 6-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.
6.2 PIM-DM Features Supported by the S5700

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.
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.
6.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
6.3.2 Enabling IPv4 Multicast Routing

Prior to configuring all IPv4 multicast features, enable IPv4 multicast routing.
Context
Do as follows on the switch:

Procedure
Step 1 Run:
system-view
Step 2 Run:
IPv4 multicast routing is enabled in the public network.
----End
6.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
When switchs 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, or an Loopback 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 interface [ interface-type interface-number | up | down ]
[ verbose ] to check PIM on interfaces of the public network.
l Run the command display pim neighbor [ neighbor-address | interface interface-type
interface-number | verbose ] * to check PIM neighbors of the public network.
----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: -
6.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 a unicast routing protocol
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
6.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
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
6.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
Do as follows on the PIM switch:
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim

Step 3 Run:
source-policy acl-number
The filter is configured.

The effect of the filtering is more obvious if the filter is closer to the source.
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
addresses that pass the filtering are forwarded.
----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.
– display pim routing-table [ group-address [ mask { group-mask-length | group-
mask } ] | source-address [ mask { source-mask-length | source-mask } ] | incoming-

interface { interface-type interface-number | register } | outgoing-interface

{ include | exclude | match } { interface-type interface-number | register | none } |
mode { dm | sm | ssm } | flags flag-value | fsm ] * [ outgoing-interface-number
[ number ] ]
[ number ] ]
– display pim routing-table brief [ group-address [ mask { group-mask-length | group-
interface { interface-type interface-number | register } ] *
----End
6.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 S5700, 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
6.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:
pim

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

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

2. Run:


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
6.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:
pim

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
6.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:

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
6.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:
Step 3 Run:
pim neighbor-policy basic-acl-number
PIM neighbor filtering is configured.
----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 interface [ interface-type interface-number | up | down ]
[ verbose ] command to check PIM on an interface.
l Run the display pim neighbor [ neighbor-address | interface interface-type interface-
number | verbose ] * command to check information about a PIM neighbor.
----End
6.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.

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
6.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:
pim

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
The period during which the downstream interface is in the Prune state is set.
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
6.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:
pim

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
6.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:
pim

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
The interval for overriding the prune action is set.
----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
[ verbose ] command to check information about PIM on an interface.
l Run the display pim 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.
[ number ] ]
[ number ] ]
----End

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

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
6.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:

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
6.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:
pim

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
keeping the Prune state.
l You can run the holdtime join-prune command to set the timeout period for keeping the Prune state.
----End
6.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:
pim
Step 3 Run:
state-refresh-rate-limit interval
The period for waiting to receive the next State-Refresh message is set.
----End
6.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:
pim
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
number ] * command to check the number of the sent or received PIM control messages.
[ number ] ]
[ number ] ]
----End

6.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
6.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:
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
number ] * command to check the number of the sent or received PIM control messages.
mode { dm |sm | ssm } | flags flag-value | fsm ] * [ outgoing-interface-number
[ number ] ]
[ number ] ]


----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
6.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:
pim

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
number ] * command to check the number of sent or received PIM control messages.
[ number ] ]
[ number ] ]
----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
6.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:

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
----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: -
6.11 Maintaining PIM-DM (IPv4)

Maintaining PIM-DM involves resetting PIM statistics, and monitoring PIM running status.
6.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 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
6.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 claimed-route [ source-address ] command in any view to check the
unicast routes used by PIM.
ack | hello | join-prune | state-refresh | bsr } | interface interface-type interface-
number ] * command in any view to check the number of sent or received PIM control
messages.
[ verbose ] command to check information about PIM on an interface.
number | verbose ] * command to check information about a PIM neighbor.
[ number ] ]
----End
6.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 S5700 Series Ethernet
Switches Debugging Reference.
Procedure
l Run the debugging pim all command in the user view to enable all the debugging of PIM.
l Run the debugging pim event [ advanced-acl-number ] command in the user view to enable
the debugging of PIM events.
l Run the debugging pim routing-table [ advanced-acl-number ] command in the user view
to enable the debugging of PIM routes.
l Run the debugging pim neighbor [ basic-acl-number | [ receive | send ] ] * command in
the user view to enable the debugging of PIM neighbors.

l Run the debugging pim assert [ advanced-acl-number | [ receive | send ] ] * command in

the user view to enable the debugging of PIM Assert.
l Run the debugging pim join-prune [ advanced-acl-number | [ receive | send ] ] * command
in the user view to enable the debugging of PIM Join/Prune.
l Run the debugging pim state-refresh [ advanced-acl-number | [ receive | send ] ] *
command in the user view to enable the debugging of PIM State-Refresh.
----End

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

SwitchA Ethernet
Receiver
GE0/0/2 HostA
Ethernet
GE0/0/1 N1
PIM-DM
Source GE0/0/3 Leaf network
GE0/0/4
GE0/0/1 GE0/0/2
SwitchD
N2
GE0/0/2 GE0/0/1 SwitchB
GE0/0/1 Receiver
HostB
GE0/0/2
Ethernet
SwitchC
Switch Physical interfaces VLANIF interface IP address

Switch A GE0/0/1 VLANIF100 192.168.1.1/24
GE0/0/2 VLANIF101 10.110.1.1/24
Switch B GE0/0/1 VLANIF200 192.168.2.1/24
GE0/0/2 VLANIF102 10.110.2.1/24
Switch C GE0/0/1 VLANIF300 192.168.3.1/24

GE0/0/2 VLANIF102 10.110.2.2/24

Switch D GE0/0/1 VLANIF200 192.168.2.2/24
GE0/0/2 VLANIF300 192.168.3.2/24
GE0/0/3 VLANIF100 192.168.1.2/24
GE0/0/4 VLANIF103 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 Switch A to protect Switch A from Hello message attacks.
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 the switch.
3. Enable PIM-DM on each interface.
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 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 Configuring IP Addresses for
Interfaces in the Quidway S5700 Series Ethernet Switches Configuration Guide - Basic
Configuration. For details on how to configure OSPF, see OSPF Configuration in the Quidway
S5700 Series Ethernet Switches Configuration Guide - IP Routing.
Step 2 Enable multicast on all switches and enable PIM-DM on all interfaces.
# Enable multicast on Switch A and enable PIM-DM on each interface. The configurations of
Switch B, Switch C, and Switch D are similar to the configuration of Switch A, and are not
provided here.
[SwitchA-Vlanif100] pim dm

[SwitchA-Vlanif101] pim dm
Step 3 Configure the interfaces connected to hosts to be PIM silent and configure IGMP on the interface.
# On Switch A, configure the vlanif interfaces connected to hosts to be PIM silent, and configure
IGMP on the interface. The configurations of Switch B, Switch C, and Switch D are similar to
configuration of Switch A, 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 Switch D 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 1 30 1 192.168.2.2(local)
Vlanif300 up 1 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 Switch D 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 Switch A and
Switch D that are in the SPT. When HostA joins multicast group G, an (*, G) entry is generated
on Switch A. The information displayed on Switch B and Switch C is similar to the information
displayed on Switch A. 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
l Configuration file of SwitchB

#
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
l Configuration file of SwitchC
#
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
l Configuration file of SwitchD
#
sysname SwitchD
#
#
vlan batch 100 103 200 300
#
interface Vlanif 100
ip address 192.168.1.2 255.255.255.0

pim dm
#
ip address 10.110.5.1 255.255.255.0
pim dm
#
ip address 192.168.2.2 255.255.255.0
pim dm
#
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 7 PIM-SM (IPv4) Configuration
7 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.
7.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.
7.2 PIM-SM Features Supported by the S5700
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.
7.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.
7.4 Adjusting Control Parameters for a Multicast Source
7.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.
7.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.
7.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.
7.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.
7.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.
7.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.
7.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.
7.14 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.

7.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.
NOTE
The S5700SI and S5706 do not support PIM-SM.
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 7-1, PIM-SM is used in a large-scale network with sparsely distributed
group members.
Figure 7-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.
7.2 PIM-SM Features Supported by the S5700

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
l Neighbor filtering function: An interface sets up neighbor relationships with only the
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 S5700, 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 S5700 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.
7.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.

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 dynamic RP: To obtain the 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
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 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
7.3.2 Enabling IP Multicast Routing

Prior to configuring all IPv4 multicast features, enable IPv4 multicast routing.
Procedure
Step 1 Run:
system-view
Step 2 Run:
IP multicast routing is enabled in the public network instance.
----End
7.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
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:

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
7.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:
pim

Step 3 Run:
static-rp rp-address basic-acl-number [ preferred ]
----End
7.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:
pim

Step 3 Run:
c-rp interface-type interface-number [ group-policy basic-acl-number | 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 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
7.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:
pim
Step 3 Run:
ssm-policy basic-acl-number
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
number | verbose ] * command to check a PIM neighbor.
[ number ] ]
[ number ] ]

l Run the display pim rp-info [ group-address ] command to check the RP in a PIM-SM
domain.
----End
7.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 S5700 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

7.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:
pim
Step 3 Run:
source-lifetime interval
The lifetime of a source is configured.
If the lifetime of the source expires, the (S, G) entry becomes invalid.
----End
7.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:
pim
Step 3 Run:
source-policy acl-number
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
addresses that pass the filtering are forwarded.
----End

After the control parameters of a multicast source are adjusted, you can run commands to check
Procedure
[ number ] ]
----End
7.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.

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 S5700 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
7.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:
pim


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
7.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:
pim

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

7.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:
pim
Step 3 Run:
bsr-policy basic-acl-number
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.
----End
7.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:
pim
Step 3 Run:
crp-policy advanced-acl-number
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.
----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 bsr-info command to check the BSR in a PIM-SM domain.
domain.
----End
7.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 S5700 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
7.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:
pim
Step 3 Run:
c-bsr admin-scope
The division of BSR administrative domains is enabled in a PIM-SM network.
----End
7.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:
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
7.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:
pim

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:
pim

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
l Run the display pim bsr-info command to check the BSR in a PIM-SM domain.
domain.
----End
7.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.

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 S5700 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
3 Interval for sending Hello messages
4 Maximum delay for triggering Hello messages
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 Number or name of the ACL used to filter PIM neighbors
7.7.2 Configuring Control Parameters for Establishing the

Neighbor Relationship
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-SM switch.
NOTE

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

2. Run:
pim

3. Run:
timer hello interval

4. Run:
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.
1. Run:
system-view

2. Run:

3. Run:
pim timer hello interval

4. Run:
pim triggered-hello-delay interval
The maximum delay for triggering Hello messages is set.
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
7.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:
pim

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.
4. Run:
pim timer dr-switch-delay interval
The DR switchover delay is configured and the delay is specified.
When an interface changes from a DR to a non-DR, the original entries are valid till
the delay expires.
By default, once an interface changes from a DR to a non-DR, the original entries are
deleted immediately.
----End

7.7.4 Enabling the Function of Tracking a Downstream 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.
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:
pim

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.

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 PIM
switchs in the shared network segment are enabled with this function.
----End
7.7.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 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:

Step 3 Run:
pim neighbor-policy basic-acl-number
PIM neighbor filtering is configured.
----End

After the neighbor control parameters are adjusted, you can run commands to check information
about the PIM interface and the PIM neighbor.
Procedure
number | verbose ] * command to check a PIM neighbor.
----End

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

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 S5700 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

No. Data
3 Timeout for keeping the suppressed state of registering
4 Interval for sending null Register messages to the RP
7.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:
pim
Step 3 Run:
register-policy advanced-acl-number
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
7.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:
pim

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

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
1 Delay for transmitting Prune messages
2 Period of overriding the Prune action
3 Timeout period of the Prune state
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
7.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:
pim

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

4. Run:
holdtime join-prune interval
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
The interval for sending Join/Prune messages is set.

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
7.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:
pim

3. Run:
hello-option lan-delay interval
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:
hello-option override-interval interval
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
7.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
A Join/Prune message received by an interface may contain both join information and prune
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:
Step 3 Run:
pim join-policy { asm basic-acl-number | ssm advanced-acl-number }
Join information filtering is configured.
----End

7.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:
pim

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


[ number ] ]
[ number ] ]
----End

If a multicast device can receive multicast data through the downstream interface, this indicates
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
7.10.2 Configuring the Period for Keeping the Assert State

The device that fails in 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 the switchs in the PIM-SM domain:
NOTE

Procedure
1. Run:
system-view

2. Run:
pim

3. Run:
holdtime assert interval
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

After the control parameters for assert are adjusted, you can check information about the PIM
commands.
Procedure
[ number ] ]
[ number ] ]
----End
7.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.

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 S5700 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

7.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:
pim

Step 3 Run:
spt-switch-threshold { traffic-rate | infinity } [ group-policy basic-acl-number
[ 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.
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
[ number ] ]


[ number ] ]
----End
7.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:
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

7.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
7.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 bfd session statistics
– display pim bfd session [ interface interface-type interface-number | neighbor
neighbor-address ] *
----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
7.13.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:


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

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

7.14 Maintaining PIM-SM (IPv4)

Maintaining PIM-SM involves resetting PIM statistics, and monitoring PIM running status.
7.14.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 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 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
7.14.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 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
7.14.3 Monitoring the Running Status of PIM-SM

running of PIM.
Context
status of PIM-SM.
Procedure
l Run the display pim claimed-route [ source-address ] command in any view to check the
unicast routes used by PIM.
l Run the display pim bfd session [ interface interface-type interface-number | neighbor
neighbor-address ] * command in any view to check information about a PIM BFD session.
number ] * command in any view to check the number of sent or received PIM control
messages.
[ verbose ] command in any view to check PIM on an interface.
l Run the command display pim 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.
[ number ] ]
[ number ] ]

l Run the display pim rp-info [ group-address ] command in any view to check information
about the RP to which a multicast group corresponds.
----End
7.14.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 all command in the user view to enable all the debugging of PIM.
l Run the debugging pim event [ advanced-acl-number ] command in the user view to enable
the debugging of PIM events.
l Run the debugging pim routing-table [ advanced-acl-number ] command in the user view
to enable the debugging of PIM routes.
l Run the debugging pim neighbor [ basic-acl-number | [ receive | send ] ] * command in
the user view to enable the debugging of PIM neighbors.
l Run the debugging pim assert [ advanced-acl-number | [ receive | send ] ] * command in
the user view to enable the debugging of PIM Assert.
l Run the debugging pim 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 join-prune [ advanced-acl-number | [ receive | send ] ] * command
in the user view to enable the debugging of PIM Join/Prune.
l Run the debugging pim register [ advanced-acl-number ] command in the user view to
enable the debugging of PIM Register.
l Run the debugging pim 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.

7.15.1 Example for Configuring the PIM-SM Network
As shown in Figure 7-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 7-2 Networking diagram for configuring PIM-SM multicast network

Ethernet
SwitchA N1
GE0/0/3 GE0/0/2 Receiver
Ethernet
GE0/0/1
HostA
GE0/0/2 SwitchE
Source GE0/0/3 GE0/0/3 PIM-SM Leaf networks
GE0/0/1 GE0/0/2
GE0/0/4 GE0/0/2
SwitchD Receiver
GE0/0/4 GE0/0/1 GE0/0/1
SwitchB
GE0/0/2 HostB
N2
GE0/0/1
Ethernet
SwitchC
GE 0/0/2 VLANIF 101 10.110.1.1/24
GE 0/0/3 VLANIF 200 192.168.1.1/24
GE 0/0/2 VLANIF 102 10.110.2.1/24
GE 0/0/2 VLANIF 400 192.168.3.1/24
Switch D GE 0/0/1 VLANIF 500 192.168.4.2/24
GE 0/0/2 VLANIF 200 192.168.1.2/24
GE 0/0/3 VLANIF 103 10.110.5.1/24
GE 0/0/4 VLANIF 104 10.110.4.1/24
Switch E GE 0/0/1 VLANIF 400 192.168.3.2/24
GE 0/0/2 VLANIF 300 192.168.2.2/24
GE 0/0/3 VLANIF 100 192.168.9.2/24
GE 0/0/4 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, Switch E in Figure 7-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
For details on how to configure IP addresses of interfaces, see IP Addresses Configuration in

the Quidway S5700 Series Ethernet Switches Configuration Guide - IP Service. For details on
how to configure OSPF, see OSPF Configuration in the Quidway S5700 Series Ethernet Switches
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 Switch B, Switch C, and Switch D are similar to the configuration of Switch A, and are not
provided here.
Step 3 Enable IGMP on the interfaces connected to hosts.
# Enable IGMP on the interface connecting Switch A to hosts. The configurations of Switch B,
Switch C, and Switch D are similar to configuration of Switch A, and are not provided here.
[SwitchA-Vlanif101] igmp version 3
Step 4 Enable PIM silent on Switch A.

[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 Switch
E.
[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 Switch B, Switch C, Switch D,
and Switch E are similar to configuration on Switch A, 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 Switch D 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
Switch B, Switch C, Switch D, and Switch E are the same as the configuration of Switch A, and
are not provided here.
[SwitchA-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[SwitchA-acl-basic-2000] quit
[SwitchA] pim
[SwitchA-pim] ssm-policy 2000

# 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 Switch C is as follows:
[SwitchC] display pim interface
Interface State NbrCnt HelloInt DR-Pri DR-Address
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 Switch A and Switch E (including the C-BSR
information on Switch E) 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 AdminScoped BSR Count: 0
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
Hash mask length: 30
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 Switch A 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: Vlanif 100,
RPF neighbor: 192.168.9.2
1: Vlanif 101
(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: Vlanif 200
1: vlanif101
Protocol: pim-sm, UpTime: 00:00:42, Expires:-


(10.110.5.100, 225.1.1.1)
RP: 192.168.9.2
UpTime: 00:00:42
Upstream interface: vlanif103
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
#
#
#
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 Vlanif200
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
#
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 Switch E
#
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 2008 priority 0
static-rp 192.168.2.2
ssm-policy 2000
#
return
7.15.2 Example for Configuring PIM BFD
On the multicast network shown in Figure 7-3, PIM-SM is run between switches. Hosts receive
the VOD information from the multicast source. Switch A is the DR on the source side. Switch
B and Switch C 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 7-3 Configuring the PIM BFD networking in the shared network segment
SwitchA
Source
10.1.7.1/24 PIM-SM GE0/0/1
SwitchC
GE0/0/1
GE0/0/2
SwitchB
GE0/0/2
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
For details on how to configure IP addresses of interfaces, see IP Addresses Configuration in

the Quidway S5700 Series Ethernet Switches Configuration Guide - IP Service. For details on
how to configure OSPF, see OSPF Configuration in the Quidway S5700 Series Ethernet Switches
Configuration Guide - IP Routing.

Step 2 Enable BFD globally and configure PIM BFD in the interface view.
# Enable BFD globally on Switch B and Switch C, 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 Switch C is similar to the configuration on Switch B 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 200 min-rx-interval 200 detect-
multiplier 3
Step 3 Configure the PIM DR switchover delay.

# Configure PIM DR switchover delay on Switch B 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 Switch
B indicates that the DR on the network segment where the host is located is Switch C. 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: 200 ms
PIM BFD min-rx-interval: 200 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 200 200 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
Upstream interface: vlanif200,
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 Switch B. The configuration file of Switch C is
similar to the configuration file of Switch B, 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 200 min-rx-interval 200 detect-multiplier 3
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

Configuration Guide - Multicast 8 MSDP Configuration
8 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.
8.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.
8.2 MSDP Features Supported by the S5700
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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.8 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.
8.9 Configuring MSDP Authentication
MSDP peer authentication contains MSDP MD5 authentication and Key-Chain authentication.
You can choose either authentication mode.
8.10 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.

8.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.
NOTE
The S5700SI and S5706 do not support MSDP.
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.
8.2 MSDP Features Supported by the S5700

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.
NOTE
The S5700SI does not support 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 S5700, 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 S5700 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.
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.
8.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
8.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
MSDP is enabled in the public network instance 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
8.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
MSDP is enabled in the public network 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
8.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
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 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 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
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 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
8.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
8.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
8.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:
pim

Step 3 Run:
c-rp loopback interface-number

An interface is configured as a C-RP.
----End
8.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.
Do as follows on all switchs in the PIM-SM domain:
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim

Step 3 Run:
static-rp rp-address
The loopback interface address is configured as a static RP address.
----End
8.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
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
8.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:
msdp
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
l Run the display msdp brief command to check the the brief information of the MSDP peer
status.
l Run the display pim 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 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: -
8.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
8.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:
msdp
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
8.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:
msdp
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
l Run the display msdp 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 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
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
8.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
8.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:
msdp

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
8.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:
msdp

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 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.
l Run the display msdp 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.
----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: 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: 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
8.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
8.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:
msdp

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
8.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:
msdp

Step 3 Run:
peer peer-address sa-request-policy [ acl basic-acl-number ]
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

8.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
l Run the display msdp peer-status [ peer-address ] command to check detailed information
about the MSDP peer status.
4-byte-as-number } ] * command to check SA Cache of the public network.
----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:
Information about connection status:
State: Up
Up/down time: 00:26:41
Resets: 0
Connection interface: Vlanif10 (172.40.41.2)
Number of sent/received messages: 27/28
Number of discarded output messages: 0
Elapsed time since last connection or counters clear: 00:26:56
Information about (Source, Group)-based SA filtering policy:
Import policy: none
Export policy: none
Information about SA-Requests:
Policy to accept SA-Request messages: 2000
Sending SA-Requests status: enable
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: 16/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: Key-Chain
8.8 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
8.8.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:
msdp
Step 3 Run:
import-source [ acl acl-number ]
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
8.8.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:
msdp

Step 3 Run:
peer peer-address sa-policy import [ acl { advanced-acl-number } ]
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
8.8.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:
msdp
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
4-byte-as-number } ] * command to check SA Cache of the public network instance.
about the MSDP peer status.
----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
SAs learned from this peer: 0, SA Cache maximum for the peer: 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.
<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
8.9 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

8.9.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:
msdp

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
8.9.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:
msdp

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
l Run the display msdp brief command to check brief information about MSDP peers.
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
SAs learned from this peer: 0, SA-cache maximum for the peer: none
Peer authentication: configured
Peer authentication type: KeyChain
8.10 Maintaining MSDP

Maintaining MSDP involves clearing MSDP peer statistics and (S, G) information in the SA
cache, and monitoring MSDP running status.
8.10.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 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 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, if MSDP
peers are not reset.
l Run the reset msdp control-message counters [ peer peer-address ] command in the user
view to clear the statistics about the received, sent, and discarded MSDP messages.
----End
8.10.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
before you use the command.
Procedure
l Run the reset msdp sa-cache [ group-address ] command in the user view to clear the
entries in MSDP SA Cache.
----End
8.10.3 Monitoring the Running Status of MSDP

running of MSDP.
Context
status of MSDP.
Procedure
l Run the display msdp brief [ state { connect | down | listen | shutdown | up } ] command
in any view to check brief information about the MSDP peer status.
l Run the display 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.
4-byte-as-number } ] * command in any view to check the (S, G) information in SA Cache.
l Run the display msdp 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 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
8.10.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 all command in the user view to enable all the debugging of
MSDP.
l Run the debugging msdp connect command in the user view to enable the debugging of
the resetting of the MSDP peer connection.
l Run the debugging msdp event command in the user view to enable the debugging of
MSDP events.
l Run the debugging msdp packet command in the user view to enable the debugging of
MSDP packets.
l Run the debugging msdp 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.
8.11.1 Example for Configuring Basic MSDP Functions
As shown in Figure 8-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 8-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 GE0/0/1
GE0/0/2 GE0/0/1 GE0/0/1 GE0/0/2
GE0/0/2 GE0/0/2
GE0/0/1 SwitchB GE0/0/3 SwitchD
PIM-SM1
SwitchF
S1 GE0/0/3
GE0/0/2
GE0/0/2
GE0/0/1
SwitchE
PIM-SM3
S3
Loopback0
3.3.3.3/32
MSDP peer

GE 0/0/2 VLANIF 100 192.168.1.1/24
GE 0/0/2 VLANIF 100 192.168.1.2/24
GE 0/0/2 VLANIF 300 192.168.3.1/24
GE 0/0/3 VLANIF 400 192.168.4.1/24
Switch D GE 0/0/1 VLANIF 102 10.110.2.1/24
GE 0/0/2 VLANIF 300 192.168.3.2/24
Switch E GE 0/0/2 VLANIF 500 192.168.5.1/24
GE 0/0/3 VLANIF 400 192.168.4.2/24
Switch F GE 0/0/1 VLANIF 103 10.110.3.1/24
GE 0/0/2 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 CBSR 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 Switch A and Switch B belong to, namely 100, and router ID of
Switch B, namely, 1.1.1.1
l Number of the AS that Switch C and Switch D belong to, namely 200, and Router ID of
Switch C, namely, 2.2.2.2
l Number of the AS that Switch E and Switch F 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 8-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 Switch B 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 Switch C 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 Switch B. The configuration on Switch C is similar to the
configuration on Switch B, 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 Switch B and enable PIM-SM on each interface. The configurations of
other switches are similar to the configuration of Switch B, 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 Switch B.

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

# Create Loopback0, and then configure a CBSR, and a C-RP on Loopback0 on Switch B. The
configurations of Switch C and Switch E are similar to the configuration of Switch B, 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] cBsr loopback 0
[SwitchB-pim] c-rp loopback 0
[SwitchB-pim] quit
Step 5 Configure MSDP peer relations.

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

[SwitchC] msdp
[SwitchC-msdp] peer 192.168.2.1 connect-interface vlanif200
[SwitchC-msdp] peer 192.168.4.2 connect-interface vlanif400
[SwitchC-msdp] quit
# Configure the MSDP peer relationship on Switch E.

[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 Switch B and Switch
C:
[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 Switch C 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 Switch
B, Switch C and Switch E 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 Switch B 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)
Information about (Source, Group)Based SA filtering policy:
Import policy: none
Export policy: none
Policy to accept SA-Request messages: none
Sending SA-Requests status: disable
SAs learned from this peer: 0, SACache maximum for the peer: none
Peer authentication: unconfigured
Peer authentication type: none
# 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 Switch B and Switch C are as
follows:
[SwitchB] display pim routing-table
(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 Vlanif101
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
peer 192.168.2.1 as-number 100
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 Switch E
#
sysname SwitchE
#
vlan batch 400 500
#

#
ip address 192.168.4.2 255.255.255.0
pim sm
pim bsr-boundary
#
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 Switch F

#
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

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

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.
NOTE
The S5700SI and S5706 do not support IPv4 Multicast Route Management.
In the S5700, 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 S5700
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.
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 S5700 Series Ethernet Switches 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 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 static [ config ] [ source-address { mask | mask-
length } ] command to check the static multicast routing table.
l Run the display multicast 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
environment, pre-configuration tasks, and required data. This can help you complete the
configuration task quickly and accurately.

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

----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
The 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 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
l Public network instance
1. Run:
system-view

2. Run:
multicast load-splitting { source | group | source-group }
Multicast load balancing is configured.

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.
----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:
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.
Step 3 Run:
multicast load-splitting weight weight-value
The multicast load splitting weight is set on the interface.
----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 routing-table [ group-address [ mask { group-mask | group-mask-
length } ] | source-address [ mask { source-mask | source-mask-length } ] | incoming-
{ include | exclude | match } { interface-type interface-number | register | none } ] *
[ outgoing-interface-number [ number ] ]
l Run the following command to check the source-specific RPF route.

display multicast rpf-info source-address [ group-address ] [ rpt | spt ]
----End
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.5.1 Establish the Configuration Task

Before configuring the 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.
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:

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.
l Run the display multicast 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
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.

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
By default, the maximum number supported by the system is used.
Procedure
l Run:
system-view

l 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.
Procedure
l Run:
system-view

l 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.
----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 forwarding-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
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.
Procedure
l Run the following commands to clear the forwarding entries in the multicast forwarding
table.
– reset multicast forwarding-table all
– reset multicast forwarding-table { group-address [ mask { group-mask | group-mask-
interface { interface-type interface-number | register } } *
l Run the following commands to clear the routing entries in the multicast routing table.
– reset multicast routing-table all

– reset multicast routing-table { group-address [ mask { group-mask | group-mask-

interface { interface-type 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 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 forwarding-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
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.
l Run the display multicast routing-table static [ config ] [ source-address { mask-
length | mask } ] command in any view to check the static multicast routing table.
l Run the display multicast 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
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 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 all
– debugging mfib { no-cache | module | packet | register | route | sync | upcall | wrong-
iif } [ advanced-acl-number ]
l Run the debugging mrm { 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
GE0/0/3 GE0/0/2
GE0/0/3 PIM-DM GE0/0/2
SwitchA SwitchB
GE0/0/1 GE0/0/1
GE0/0/2 GE0/0/3
8.1.1.2/24
7.1.1.2/24
Source Receiver
Multicast static route

GE 0/0/2 VLANIF 20 8.1.1.1/24
GE 0/0/3 VLANIF 30 12.1.1.1/24
GE 0/0/2 VLANIF 40 13.1.1.1/24
GE 0/0/3 VLANIF 50 7.1.1.1/24
GE 0/0/3 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 SwitchC: VLANIF 40

NOTE
This configuration example describes only the commands used to configure static multicast routes.
Procedure
Step 1 Configure the IP addresses of interfaces and the unicast routing protocol on each switch.
# 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] multicast routing-enable
[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.
[SwitchB] display multicast rpf-info 8.1.1.2
RPF information about source 8.1.1.2:
RPF interface: vlanif40, RPF neighbor: 13.1.1.2
Referenced route/mask: 8.1.1.0/24
Referenced route type: mstatic

Route selection rule: preference-preferred

Load splitting rule: disable
----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

#
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

Configuration Guide - Multicast 10 MLD Snooping Configuration
10 MLD Snooping Configuration
About This Chapter
This chapter describes the implementation and configuration procedures of Multicast Listener
Discovery (MLD) snooping on the S5700.
10.1 Overview of MLD Snooping
When MLD snooping is enabled, the S5700 creates a Layer 2 forwarding table for multicast
data packets by listening to MLD messages. In this manner, the S5700 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.
10.2 MLD Snooping Features Supported by the S5700
This section describes the MLD snooping features supported by the S5700.
10.3 Configuring Basic Functions of 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.
10.4 Configuring a Multicast Group Policy for a VLAN
This section describes how to configure a multicast group policy for a VLAN.
10.5 Configuring Prompt Leave of Interfaces
This section describes how to configure prompt leave of interfaces in a VLAN.
10.6 Configuring the MLD Snooping Querier
This section describes how to configure the MLD snooping querier.
10.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.
10.8 Maintaining MLD Snooping
This section describes how to maintain MLD snooping.

This section provides several configuration examples of MLD snooping.

10.1 Overview of MLD Snooping

When MLD snooping is enabled, the S5700 creates a Layer 2 forwarding table for multicast
data packets by listening to MLD messages. In this manner, the S5700 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
10.2 MLD Snooping Features Supported by the S5700

This section describes the MLD snooping features supported by the S5700.
Basic Features of MLD Snooping

The S5700 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 S5700, 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 S5700 sets the
remaining aging time of the interface to 180 seconds. If the router interface receives a PIM
Hello message, the S5700 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 S5700 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 S5700 adapt
to the change of load on the network.

l Interval for sending the MLD Last Member Query messages. This timer helps the S5700
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.
Prompt Leave of Member Interfaces

When an interface of the S5700 receives an MLD Leave message of a multicast group, the
S5700 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.
10.3 Configuring Basic Functions of 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 S5700. Therefore, you need to enable MLD
snooping on the S5700 globally.
After MLD snooping is enabled on the S5700 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 S5700 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

No. Data
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
10.3.2 Enabling MLD snooping on the S5700

Context
To enable MLD snooping globally, do as follows on the S5700.
Procedure
Step 1 Run:
system-view

Step 2 Run:
mld-snooping enable
MLD snooping is enabled globally.

By default, MLD snooping is disabled on the S5700.
----End
10.3.3 Enabling MLD Snooping in a VLAN

Context
To enable MLD snooping in a VLAN, do as follows on the S5700.
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
10.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 S5700.
Procedure
Step 1 Run:
system-view
Step 2 Run the following commands as required:

l Run:

The interface can be a GE interface, an XGE, or an Eth-Trunk 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
10.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 S5700.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The interface can be a GE interface, an XGE, or an Eth-Trunk 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
10.3.6 (Optional) Setting the Maximum Number of Multicast

Groups that Hosts Attached to an Interface Can Join
Context
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 users can join.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
mld-snooping table limit table-limit vlan vlan-id
The maximum number of multicast groups that hosts attached to the interface can join.
If vlan-id is specified, the maximum number of multicast groups that hosts attached to the
interface in a specified VLAN can join is set.
----End
10.3.7 (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 S5700 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
10.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 10.3 Configuring Basic Functions of 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
10.4.2 Configuring a Multicast Group Policy

Context
To configure a multicast group policy, do as follows on the S5700.
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
10.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

10.5.2 Configuring Prompt Leave of Interfaces

Context
To configure the prompt leave function in a VLAN, do as follows on the S5700.
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 S5700 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
10.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
10.6.2 Enabling the MLD Snooping Querier
Context
Do as follows on the S5700.
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
10.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 S5700 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

10.6.4 Setting the Source IPv6 Address of MLD Query Messages
Context
Do as follows on the S5700.
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
10.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
S5700 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

10.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 S5700.
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.
By default, if the router interface receives an MLD Query message, the S5700 sets the remaining
aging time of the interface to 180 seconds.
----End
10.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
10.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
S5700.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
mld-snooping require-router-alert
The S5700 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 S5700 is configured to send only the MLD messages that contain the Router Alert option
in the IP header.
By default, the S5700 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
10.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 S5700.

Procedure
Step 1 Run:
system-view
Step 2 Run:
mld-snooping send-query enable
The MLD snooping module of the S5700 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 S5700 is
FE80::.
Step 3 is optional. After the S5700 is enabled to respond to changes of the Layer 2 network
topology, it sends an MLD General Query message to the downstream S5700 when receiving a
Topology Change message. Then the downstream S5700 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 S5700 and its downstream S5700 can learn
the new multicast forwarding entry. This function enables the S5700 to forward multicast data
correctly after the Layer 2 topology changes.
----End
10.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 S5700.
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
10.8 Maintaining MLD Snooping

This section describes how to maintain MLD snooping.
10.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
S5700 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
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
10.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
Procedure
Step 1 Run the reset mld-snooping statistics [ vlan vlan-id ] command to clear the statistics on MLD
snooping in a VLAN.
----End
10.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.
10.9.1 Example for Configuring Prompt Leave of Interfaces in a

VLAN
As shown in Figure 10-1, GE 0/0/1 and GE 0/0/2 on of Switch A are connected to only one
receiver respectively. Other hosts connected to GE 0/0/1 and GE 0/0/2 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 10-1 Networking diagram for configuring prompt leave of interfaces in a VLAN
DHCP server multicast source
IP/MPLS
core
GE0/0/3
SwitchA
GE0/0/1 GE0/0/2
VLAN 3
Host1 Host2 Host 3 Host 4 Host 5
1. Create VLAN 3 on Switch A and add GE 0/0/1, GE 0/0/2, and GE 0/0/3 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 0/0/1, GE 0/0/2, and GE 0/0/3 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 4 Enable MLD snooping in VLAN 3.

[SwitchA-vlan3] mld-snooping enable
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 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 Enable
MLD Router Alert is Not Required
MLD Send Router Alert Enable
MLD Snooping Querier Disable
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
#
#
#

#
return


Configuration Guide - Multicast (V100R006C01 - 01)

Uploaded by

Copyright:

Available Formats

Configuration Guide - Multicast (V100R006C01 - 01)

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 (V100R006C01 - 01)

Uploaded by

Copyright:

Available Formats

Quidway S5700 Series Ethernet Switches

Configuration Guide - Multicast

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2011-10-26) 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 01 (2011-10-26) 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 01 (2011-10-26)

Issue 01 (2011-10-26) Huawei Proprietary and Confidential iii

About This Document.....................................................................................................................ii

2 IGMP Snooping Configuration..................................................................................................6

Issue 01 (2011-10-26) Huawei Proprietary and Confidential iv

2.5.4 Checking the Configuration.....................................................................................................................26

3 Multicast VLAN Replication Configuration..........................................................................36

4 Controllable Multicast Configuration.....................................................................................58

Issue 01 (2011-10-26) Huawei Proprietary and Confidential v

4.3.6 Checking the Configuration.....................................................................................................................63

6 PIM-DM (IPv4) Configuration..................................................................................................98

Issue 01 (2011-10-26) Huawei Proprietary and Confidential vi

6.4.1 Establishing the Configuration Task.....................................................................................................104

Issue 01 (2011-10-26) Huawei Proprietary and Confidential vii

7 PIM-SM (IPv4) Configuration................................................................................................135

Issue 01 (2011-10-26) Huawei Proprietary and Confidential viii

7.9 Adjusting Control Parameters for Forwarding...............................................................................................165

Issue 01 (2011-10-26) Huawei Proprietary and Confidential ix

8.4.1 Establishing the Configuration Task.....................................................................................................207

9 IPv4 Multicast Routing Management....................................................................................241

Issue 01 (2011-10-26) Huawei Proprietary and Confidential x

9.2 IPv4 Multicast Routing Management Features Supported by the S5700.......................................................243

10 MLD Snooping Configuration..............................................................................................263

Issue 01 (2011-10-26) Huawei Proprietary and Confidential xi

10.4.1 Establishing the Configuration Task...................................................................................................271

Issue 01 (2011-10-26) Huawei Proprietary and Confidential xii

1 IP Multicast Configuration Guide

About This Chapter

1.1 IP Multicast Overview

Issue 01 (2011-10-26) Huawei Proprietary and Confidential 1

1.1 IP Multicast Overview

The S5700SI and S5706 do not support L3 Multicast.

The multicast technology applied to IPv4 and IPv6 is called IP multicast.

1.2 IP Multicast Features Supported by the S5700

1.3 IPv4 Multicast Configuration Guide

1.3.1 IPv4 Multicast Addresses

Table 1-1 Class D addresses