Configuration Guide - IP Multicast (V800R002C01 - 01) PDF

HUAWEI NetEngine5000E Core Router
V800R002C01
Configuration Guide - IP Multicast
Issue 01
Date 2011-10-15
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

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

Copyright Huawei Technologies Co., Ltd.
Configuration Guide - IP Multicast About This Document
About This Document
Intended Audience
This document provides the basic concepts, configuration procedures, and configuration
examples in different application scenarios of the IP Multicast feature supported by the
NE5000E device.
This document describes how to configure the Basic Configurations feature.
This document is intended for:
l Data configuration engineers
l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Related Versions (Optional)

The following table lists the product versions related to this document.
Product Name Version
HUAWEI NetEngine5000E V800R002C01

Core Router
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.
Indicates a hazard with a medium or low level of risk, which

if not avoided, could result in minor or moderate injury.
Issue 01 (2011-10-15) Huawei Proprietary and Confidential ii

Configuration Guide - IP Multicast About This Document
Symbol Description
Indicates a potentially hazardous situation, which if not

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

important points of the main text.
Command Conventions (Optional)

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

The initial commercial release.
Issue 01 (2011-10-15) Huawei Proprietary and Confidential iii

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

1 IP Multicast Configuration..........................................................................................................1
1.1 IP Multicast Overview........................................................................................................................................2
1.2 Typical Configuration Scheme...........................................................................................................................5
2 IGMP Configuration.....................................................................................................................8
2.1 IGMP Overview...............................................................................................................................................10
2.2 IGMP Features Supported by the NE5000E.....................................................................................................10
2.3 Configuring Basic IGMP Functions.................................................................................................................11
2.3.1 Enabling Multicast Routing.....................................................................................................................12
2.3.2 Enabling PIM-SM....................................................................................................................................13
2.3.3 Enabling IGMP........................................................................................................................................14
2.3.4 (Optional) Setting an IGMP Version.......................................................................................................15
2.3.5 (Optional) Configuring an Interface to Statically Join an IGMP Group.................................................15
2.3.6 (Optional) Setting the Range of Multicast Groups that an Interface Can Join........................................16
2.3.7 Checking the Configuration.....................................................................................................................16
2.4 Configuring IGMP SSM Mapping...................................................................................................................18
2.4.1 Enabling SSM Mapping..........................................................................................................................18
2.4.2 Configuring Static SSM Mapping...........................................................................................................19
2.5 Configuring an IGMP Router-Alert Option.....................................................................................................21
2.5.1 Configuring a Multicast Device to Deny IGMP Packets Without Router-Alert Options.......................22
2.5.2 Configuring a Multicast Device to Send IGMP Packets Without Router-Alert Options........................23
2.6 Configuring an IGMP Querier..........................................................................................................................25
2.6.1 Configuring an IGMPv1 Querier.............................................................................................................25
2.6.2 Configuring an IGMPv2/v3 Querier........................................................................................................27
2.7 Maintaining IGMP............................................................................................................................................30
2.7.1 Clearing IGMP Group Information.........................................................................................................30
2.7.2 Monitoring the Operating Status of IGMP..............................................................................................31
2.8 Configuration Examples...................................................................................................................................31
2.8.1 Example for Configuring Basic IGMP Functions...................................................................................32
Issue 01 (2011-10-15) Huawei Proprietary and Confidential iv

2.8.2 Example for Configuring IGMP SSM Mapping.....................................................................................36
3 PIM Configuration......................................................................................................................43
3.1 PIM Overview..................................................................................................................................................45
3.2 PIM Features Supported by the NE5000E.......................................................................................................47
3.3 Configuring PIM-SM.......................................................................................................................................49
3.3.2 Enabling PIM-SM....................................................................................................................................52
3.3.3 Configuring a Static RP...........................................................................................................................53
3.3.4 Configuring a BSR RP............................................................................................................................54
3.3.5 (Optional) Setting a Multicast Source Address Range............................................................................55
3.3.6 (Optional) Adjusting Source Registration Parameters............................................................................56
3.3.7 (Optional) Configuring SPT Switchover Conditions..............................................................................58
3.4 Configuring a BSR Boundary...........................................................................................................................61
3.5 Adjusting BSR RP Parameters.........................................................................................................................62
3.5.1 Adjusting C-RP Parameters.....................................................................................................................63
3.5.2 Setting a Legal C-RP Address Range......................................................................................................64
3.5.3 Adjusting C-BSR Parameters..................................................................................................................65
3.5.4 Setting a Legal BSR Address Range.......................................................................................................66
3.5.5 Configuring a BSR Administrative Domain...........................................................................................67
3.6 Configuring PIM-SSM.....................................................................................................................................69
3.6.2 Enabling PIM-SM....................................................................................................................................71
3.6.3 Setting an SSM Group Address Range....................................................................................................72
3.6.4 (Optional) Setting a Multicast Source Address Range............................................................................73
3.7 Adjusting Other PIM Parameters.....................................................................................................................75
3.7.1 Adjusting the Lifetime of a Source..........................................................................................................75
3.7.2 Adjusting Neighbor Parameters...............................................................................................................76
3.7.3 Adjusting DR Parameters........................................................................................................................78
3.7.4 Adjusting Forwarding Parameters...........................................................................................................79
3.7.5 Adjusting Assert Parameters...................................................................................................................82
3.8 Configuring PIM BFD......................................................................................................................................85
3.8.1 Enabling PIM BFD..................................................................................................................................85
3.8.2 (Optional) Adjusting BFD Parameters....................................................................................................86
3.9 Maintaining PIM...............................................................................................................................................87
3.9.1 Clearing Statistics of PIM Control Messages..........................................................................................87
3.9.2 Monitoring the Running Status of PIM...................................................................................................88
3.10 Configuration Examples.................................................................................................................................89
Issue 01 (2011-10-15) Huawei Proprietary and Confidential v

3.10.1 Example for Configuring PIM-SM Intra-domain Multicast..................................................................89

3.10.2 Example for Configuring a PIM-SM BSR Administrative Domain.....................................................97
3.10.3 Example for Configuring PIM-SM Security.......................................................................................105
3.10.4 Example for Configuring SPT Switchover in a PIM-SM Domain......................................................113
3.10.5 Example for Configuring PIM-SSM Multicast...................................................................................122
4 MSDP Configuration................................................................................................................127
4.1 MSDP Overview.............................................................................................................................................129
4.2 MSDP Features Supported by the NE5000E..................................................................................................129
4.3 Configuring PIM-SM Inter-domain Multicast...............................................................................................131
4.3.1 Configuring Intra-AS MSDP Peers.......................................................................................................132
4.3.2 Configuring Inter-AS MSDP Peers for BGP Peers...............................................................................133
4.3.3 Configuring Inter-AS Static RPF Peers.................................................................................................134
4.3.4 Checking the Configuration...................................................................................................................135
4.4 Configuring Anycast RP.................................................................................................................................136
4.4.1 Configuring the RP Address on a Loopback Interface..........................................................................137
4.4.2 Configuring a Loopback Interface as an RP..........................................................................................138
4.4.3 Configuring MSDP Peers on RPs..........................................................................................................139
4.4.4 Specifying a Logical RP Address for SA Messages..............................................................................140
4.5 Controlling MSDP Peer Connections.............................................................................................................142
4.5.1 Closing an MSDP Peer Connection.......................................................................................................143
4.5.2 Adjusting the Interval for Retrying to Set Up an MSDP Peer Connection...........................................143
4.5.3 Configuring MSDP Peer Authentication...............................................................................................144
4.6 Adjusting the Parameters of SA Messages.....................................................................................................145
4.6.1 Configuring an SA Cache......................................................................................................................146
4.6.2 Configuring Filtering Policies for SA Messages...................................................................................147
4.7 Maintaining MSDP.........................................................................................................................................151
4.7.1 Clearing Statistics of MSDP Peers........................................................................................................151
4.7.2 Clearing (S, G) Information from an SA Cache....................................................................................151
4.7.3 Monitoring the Running Status of MSDP.............................................................................................152
4.8.1 Example for Configuring PIM-SM Inter-domain Multicast..................................................................152
4.8.2 Example for Configuring Inter-AS Multicast by Using Static RPF Peers............................................160
4.8.3 Example for Configuring Anycast RP...................................................................................................165
5 MBGP Configuration................................................................................................................172
5.1 MBGP Overview............................................................................................................................................174
5.2 MBGP Features Supported by the NE5000E.................................................................................................174
5.3 Configuring an MBGP Peer...........................................................................................................................174
5.4 Configuring MBGP to Import Local Routes..................................................................................................176
5.5 Controlling MBGP Route Advertisement......................................................................................................178
Issue 01 (2011-10-15) Huawei Proprietary and Confidential vi

5.5.1 Summarizing Local MBGP Routes.......................................................................................................178

5.5.2 Configuring MBGP to Advertise Default Routes to Peers....................................................................180
5.5.3 Configuring MBGP to Advertise the Community Attribute.................................................................181
5.6 Controlling MBGP Route Selection...............................................................................................................182
5.6.1 Configuring Preferences for MBGP Routes..........................................................................................183
5.6.2 Setting a Preferred Value for Routes Learned from an MBGP Peer.....................................................184
5.6.3 Setting the Local_Pref Attribute for MBGP Routes..............................................................................184
5.6.4 Setting the MED Attribute for MBGP Routes.......................................................................................185
5.6.5 Setting the Next_Hop Attribute.............................................................................................................187
5.6.6 Setting the AS_Path Attribute...............................................................................................................188
5.7 Configuring MBGP Routing Policies.............................................................................................................190
5.7.1 Configuring a Route-policy...................................................................................................................190
5.7.2 Configuring a Policy for Receiving MBGP Routes..............................................................................191
5.7.3 Configuring a Policy for Advertising MBGP Routes............................................................................193
5.7.4 Configuring MBGP Soft Resetting........................................................................................................195
5.8 Configuring MBGP Load Balancing..............................................................................................................197
5.9 Configuring MBGP Route Dampening..........................................................................................................198
5.10 Configuring MBGP RRs..............................................................................................................................200
5.11 Maintaining MBGP......................................................................................................................................202
5.11.1 Resetting MBGP Connections.............................................................................................................202
5.11.2 Clearing MBGP Statistics....................................................................................................................202
5.12 Configuration Examples...............................................................................................................................203
5.12.1 Example for Configuring Basic MBGP Functions..............................................................................203
6 IP Multicast Routing Management........................................................................................212

6.1 Introduction to IP Multicast Routing Management........................................................................................213
6.2 IP Multicast Routing Management Features Supported by the NE5000E.....................................................213
6.3 Configuring RPF Routes................................................................................................................................214
6.3.1 Configuring Multicast Static Routes.....................................................................................................215
6.3.2 Configuring Multicast Load Splitting....................................................................................................217
6.4 Adjusting the Minimum TTL Value for Multicast Forwarding.....................................................................219
6.5.1 Example for Configuring Multicast Static Routes to Change RPF Routes...........................................220
6.5.2 Example for Configuring Multicast Static Routes to Connect RPF Routes..........................................225
6.5.3 Example for Configuring Multicast Load Splitting...............................................................................229
7 MLD Configuration..................................................................................................................236
7.1 MLD Overview...............................................................................................................................................238
7.2 MLD Features Supported by the NE5000E....................................................................................................238
7.3 Configuring Basic MLD Functions................................................................................................................239
Issue 01 (2011-10-15) Huawei Proprietary and Confidential vii

7.3.1 Enabling IPv6 Multicast Routing..........................................................................................................240

7.3.2 Enabling IPv6 PIM-SM.........................................................................................................................241
7.3.3 Enabling MLD.......................................................................................................................................241
7.3.4 (Optional) Setting an MLD Version......................................................................................................242
7.3.5 (Optional) Configuring an Interface to Statically Join an MLD Group................................................242
7.3.6 (Optional) Setting the Range of MLD Groups that an Interface Can Join............................................243
7.4 Configuring MLD SSM Mapping..................................................................................................................245
7.4.1 Enabling the SSM Mapping Function...................................................................................................246
7.4.2 Configuring Static SSM Mapping.........................................................................................................246
7.5 Configuring an MLD Router-Alert Option....................................................................................................249
7.5.1 Configuring a Multicast Device to Deny MLD Packets Without Router-Alert Options......................249
7.5.2 Configuring a Multicast Device to Send MLD Packets Without Router-Alert Options.......................250
7.6 Configuring an MLD Querier.........................................................................................................................252
7.7 Maintaining MLD...........................................................................................................................................256
7.7.1 Clearing MLD Group Information........................................................................................................256
7.7.2 Monitoring the Operating Status of MLD.............................................................................................256
7.8.1 Example for Configuring Basic MLD Functions..................................................................................257
7.8.2 Example for Configuring MLD SSM Mapping....................................................................................262
8 IPv6 PIM Configuration...........................................................................................................269

8.1 IPv6 PIM Overview........................................................................................................................................271
8.2 IPv6 PIM Features Supported by the NE5000E.............................................................................................272
8.3 Configuring IPv6 PIM-SM.............................................................................................................................274
8.3.3 Configuring an Embedded-RP...............................................................................................................277
8.3.4 Configuring a Static RP.........................................................................................................................277
8.3.5 Configuring a BSR RP..........................................................................................................................278
8.3.6 (Optional) Limiting the Range of Multicast Source Addresses............................................................280
8.3.7 (Optional) Adjusting Control Parameters for Source Registration.......................................................280
8.3.8 (Optional) Configuring SPT Switchover Conditions............................................................................282
8.4 Configuring a BSR Boundary (IPv6).............................................................................................................285
8.5 Adjusting Dynamic RP Parameters (IPv6).....................................................................................................286
8.5.1 Adjusting C-RP Parameters...................................................................................................................287
8.5.2 Setting the Range of Valid C-RP Addresses.........................................................................................288
8.5.3 Adjusting C-BSR Parameters................................................................................................................289
8.5.4 Setting the Range of Valid BSR Addresses...........................................................................................290
Issue 01 (2011-10-15) Huawei Proprietary and Confidential viii

8.6 Configuring IPv6 PIM-SSM...........................................................................................................................292

8.6.3 Setting an SSM Group Address Range..................................................................................................294
8.6.4 (Optional) Limiting the Range of Multicast Source Addresses............................................................295
8.7 Adjusting Other IPv6 PIM Parameters...........................................................................................................297
8.7.1 Adjusting the Lifetime of a Source........................................................................................................297
8.7.2 Adjusting Control Parameters for Maintaining Neighbor Relationships..............................................298
8.7.3 Adjusting DR Parameters......................................................................................................................300
8.7.4 Adjusting Control Parameters for Forwarding......................................................................................301
8.7.5 Adjusting Assert Parameters.................................................................................................................304
8.8 Maintaining IPv6 PIM....................................................................................................................................307
8.8.1 Resetting Statistics About IPv6 PIM Control Messages.......................................................................307
8.8.2 Monitoring the Operating Status of IPv6 PIM......................................................................................307
8.9.1 Example for Configuring IPv6 PIM-SM Intra-domain Multicast.........................................................308
8.9.2 Example for Configuring IPv6 PIM-SM Security.................................................................................316
9 IPv6 Multicast Routing Management....................................................................................325

9.1 Overview of IPv6 Multicast Routing Management........................................................................................326
9.2 IPv6 Multicast Route Management Features Supported by the NE5000E....................................................326
9.3 Configuring IPv6 Multicast Load Splitting....................................................................................................327
9.4 Controlling the IPv6 Multicast Forwarding Range........................................................................................328
9.4.1 Setting a Minimum TTL Value for IPv6 Multicast Packets..................................................................329
9.4.2 Configuring an IPv6 Multicast Forwarding Boundary..........................................................................329
9.5.1 Example for Configuring IPv6 Multicast Load Splitting......................................................................330
Issue 01 (2011-10-15) Huawei Proprietary and Confidential ix

Configuration Guide - IP Multicast 1 IP Multicast Configuration
1 IP Multicast Configuration
About This Chapter
This section describes multicast addresses, application and function of multicast protocols, and
typical multicast configurations on an IPv4 network.
1.1 IP Multicast Overview

Multicast is mainly used in a Point to Multi-Point (P2MP) data transmission scenario. It ensures
information security on the network and consumes low network bandwidth.
1.2 Typical Configuration Scheme
Typical multicast configuration schemes on a network include PIM-SM intra-domain multicast,
PIM-SM inter-domain multicast, and PIM-SSM multicast.
Issue 01 (2011-10-15) Huawei Proprietary and Confidential 1

1.1 IP Multicast Overview

Multicast is mainly used in a Point to Multi-Point (P2MP) data transmission scenario. It ensures
information security on the network and consumes low network bandwidth.
Currently, the Internet services implemented through IP multicast include IPTV, Video On
Demand (VOD), online meeting, e-learning, and remote medicine.
Basic Concepts of Multicast

l Multicast group: Each IP multicast address identifies a multicast group. Any host (or other
receiving device) that joins a multicast group becomes a member of this group and can
identify and receive the IP packets with the destination addresses being the IP multicast
address of this group.
l Multicast source: The source that takes a multicast group address as the destination address
to forward IP packets is called a multicast source. A multicast source can simultaneously
send data to multiple multicast groups. Multiple multicast sources can simultaneously send
data to a multicast group.
l Multicast group member: The members of a multicast group are dynamic. Hosts can
randomly join and leave a multicast group on a network. Members may reside in any
position of the network.
A multicast source cannot be a receiver of multicast data or a member of any multicast
group.
l Multicast router: The router that supports the multicast function on a network is called a
multicast router. A multicast router provides the following functions:
Managing group members at the leaf segment network that connects to hosts
Implementing multicast routing and guiding the forwarding of multicast packets
l Multicast distribution tree (MDT): According to the distribution of multicast group
members, the multicast routing protocol can set up a tree-type routing architecture to
forward multicast packets.
RP tree: The MDT with a Rendezvous Point (RP) as the root and group members as
leaves is called an RP tree (RPT). RPT is only applicable to the Protocol Independent
Multicast-Sparse Mode (PIM-SM).
SPT: The MDT with the multicast source as the root and group members as leaves is
called a Shortest Path Tree (SPT). SPT is applicable to the Protocol Independent
Multicast-Dense Mode (PIM-DM), PIM-SM, and Protocol Independent Multicast-
Source Specific Multicast (PIM-SSM).
IPv4 Multicast Addresses

The IPv4 multicast addresses are Class D addresses, ranging from 224.0.0.0 to 239.255.255.255.
The multicast group address available for multicast services ranges from 224.0.2.0 to
239.255.255.255.Table 1-1 lists IPv4 multicast addresses and gives a brief introduction.

Table 1-1 Range and description of IPv4 multicast addresses

Class D Address Range Description
224.0.0.0 to 224.0.1.255 The addresses in this range are group addresses reserved for
local links. The Internet Assigned Number Authority (IANA)
reserves the addresses in this range for routing protocols, and
these addresses are called permanent multicast group
addresses. The addresses are used to identify a group of
specific network devices and these devices are not involved in
multicast forwarding.
224.0.2.0 to The addresses in this range are Any-Source Multicast (ASM)

231.255.255.255 addresses.
233.0.0.0 to The addresses in this range are valid on the entire network.
238.255.255.255
232.0.0.0 to The addresses in this range are Source-Specific Multicast

232.255.255.255 (SSM) addresses. This is the default SSM group address range.
The addresses in this range are valid on the entire network.
239.0.0.0 to The addresses in this range are administration multicast

239.255.255.255 addresses. This is the default group address range of the
BootStrap Router (BSR) administrative domain. The
addresses in this range are private addresses. Each address is
valid only in the local BSR administrative domain. You can
use the same address in different BSR administrative domains.
IPv4 Multicast Protocols

To implement a complete set of IPv4 multicast services, various multicast protocols need to be
deployed on the network to cooperate with each other. Figure 1-1 shows various multicast
protocols and application position of each multicast protocol.

Figure 1-1 Application position of each IPv4 multicast protocol
IPv4 Network IPv4 Network

AS1 AS2
Source
PIM PIM
MSDP
IGMP IGMP
User User
Table 1-2 IPv4 multicast protocols

Multicast Protocol Application Function
Position
Internet Group Between hosts Connecting hosts to a multicast network:

Management Protocol and multicast l Implementing the dynamic join and
(IGMP) routers leaving of members at the host side
l Managing and maintaining the member
relationship at the router side and
exchanging information with the upper
layer multicast routing protocols
Protocol Independent Between intra- Guiding multicast routing and forwarding:

Multicast (PIM) domain multicast l Creating multicast routes on demands
routers
l Dynamically responding to the changes of
the network topology and maintaining the
multicast routing table
l Forwarding packets according to the
multicast routing table

Multicast Protocol Application Function

Position
Multicast Source Between inter- Sharing the information of inter-domain

Discovery Protocol domain multicast multicast sources:
(MSDP) routers l Routers in the domain where the source
resides transmit the local source
information to routers in other domains
l Routers in different domains exchange
source information
1.2 Typical Configuration Scheme

Typical multicast configuration schemes on a network include PIM-SM intra-domain multicast,
PIM-SM inter-domain multicast, and PIM-SSM multicast.
Multicast routing is based on unicast routes. Therefore, before configuring multicast on a

network, ensure that unicast routing is normal.
NOTE
Currently, the NE5000E supports PIM-SM, PIM-SSM, and MSDP. The NE5000Es connected to hosts
need to run IGMP-supported system versions.
Configuring PIM-SM Intra-Domain Multicast
Figure 1-2 PIM-SM intra-domain multicast
Receiver
UserA
IGMP
PIM-SM Receiver
PIM-SM IGMP
Source PIM-SM
UserB
Multicast PIM-SM PIM-SM
Receiver
Server PIM-SM IGMP
PIM-SM
UserC

As shown in Figure 1-2, unicast routing on the network is normal and there is only one PIM-
SM domain. The configuration sequence is as follows:
1. Enable multicast routing on all multicast routers.
2. Enable PIM-SM on all the interfaces of multicast routers.
3. Enable IGMP on the interfaces connecting routers to hosts.
4. Configure RPs. You can choose to use static RPs or BSR RPs. Alternatively, you can
configure MSDP to implement anycast RP.
Configuring PIM-SM Inter-domain Multicast
Figure 1-3 PIM-SM inter-domain multicast
AS100 AS200
PIM-SM1 PIM-SM4
S RP1 RP4 Receiver
PIM-SM2 PIM-SM3
C-RP2.1 C-RP2.2 C-RP3.1 C-RP3.2
MSDP Peers
As shown in Figure 1-3, unicast routing on the network is normal and there are multiple PIM-
SM domains. You can configure MSDP to implement inter-domain multicast in an AS or across
different ASs. The configuration sequence is as follows:
2. Enable PIM-SM on all router interfaces.
3. Enable IGMP on the interface connecting the router to user hosts.
4. Divide PIM-SM domains and configure RPs; configure MSDP to implement anycast RP.
l If you choose to use static RPs, you only need to configure the same static RP on the
routers in this PIM-SM domain. In this way, the range of this PIM-SM domain is
determined.

l If you choose to use BSR RPs, you need to configure BSR boundaries on the interfaces
of the routers at the edge of PIM-SM domains to limit the range of the PIM-SM domain.
Then, configure C-BSRs and C-RPs in each PIM-SM domain.
5. Set up MSDP peer relationships between RPs in different PIM-SM domains in the same
AS and add these MSDP peers to the same mesh group.
6. Set up MSDP peer relationships between RPs in different ASs. There are two available
methods:
l Set up TCP connections between the RPs through the Boarder Gateway Protocol (BGP).
l Specify the RPs as static Reverse Path Forwarding (RPF) peers of each other.
Configuring PIM-SSM Multicast

For PIM-SSM, inter-domain multicast and intra-domain multicast are not involved. Since
receivers know the location of the multicast source in advance, multicast transmission path can
be directly established with the help of partial PIM-SM functions.
When unicast routing on the network is normal and PIM-SSM needs to be used, the configuration
sequence is as follows:
2. Enable PIM-SM on all router interfaces.
3. Enable IGMP on the interface connecting the router to user hosts.
4. Set the SSM group address range on all routers.
Multicast Route Management

When basic multicast functions on a network are normal, you can perform multicast route
management as required. Multicast route management provides the following functions:
l Configuring multicast static routes to change the RPF routes
l Configuring multicast load splitting
l Configuring multicast multi-topology

Configuration Guide - IP Multicast 2 IGMP Configuration
2 IGMP Configuration
About This Chapter
To manage multicast group members on a local network, configure IGMP on the interface that
connects a multicast device to a user network segment.
2.1 IGMP Overview

IGMP is used to manage multicast groups and their members on multicast devices.
2.2 IGMP Features Supported by the NE5000E
The supported IGMP features include basic IGMP functions, Router-Alert options, IGMP
querier parameter settings, and SSM mapping.
2.3 Configuring Basic IGMP Functions
After basic IGMP functions are configured on the interfaces connecting multicast devices to the
network segments where user hosts reside, user hosts can access a multicast network and
multicast packets can reach the user hosts.
2.4 Configuring IGMP SSM Mapping
To ensure that IGMP versions on a multicast device and user hosts are compatible and enable
the multicast device running a higher version of IGMP to provide SSM services for user hosts
running a lower version of IGMP, configure SSM mapping on the multicast device.
2.5 Configuring an IGMP Router-Alert Option
In this configuration task, you can configure a device to deny all the IGMP packets without
Router-Alert options or send IGMP packets without Router-Alert options.
2.6 Configuring an IGMP Querier
An IGMP querier is responsible for periodically sending IGMP Query messages on a shared
network segment to update group memberships. Interfaces connecting multicast devices to the
same user network segment must use the same IGMP parameters; otherwise, multicast devices
on the network fail to communicate with each other.
2.7 Maintaining IGMP
Maintaining IGMP involves resetting IGMP group information, monitoring IGMP operating
status, and debugging IGMP.
2.8 Configuration Examples

Configuration examples show you how to configure basic IGMP functions and how to configure
IGMP SSM mapping.

2.1 IGMP Overview

IGMP is used to manage multicast groups and their members on multicast devices.
Multicast becomes more and more widely applied and an increasing number of hosts need to
join multicast groups and receive multicast data. How to manage multicast groups and their
members on the router becomes an important issue.
In the TCP/IP suite, the Internet Group Management Protocol (IGMP) is used to manage IPv4
multicast group members. IGMP is used on the router and directly connected user hosts to
establish and maintain group memberships.
IGMP is a signaling mechanism of hosts towards routers on the leaf network enabled with IP
multicast. IGMP can be divided into two functional parts: at the host side and at the router side.
l To participate in multicast transmission, hosts must be enabled with IGMP. Hosts can
randomly join or leave related multicast groups anytime and anywhere, and the number of
hosts is not limited.
NOTE
The Operating System (OS) of a host determines which IGMP version is supported by the host.
l Using IGMP, a multicast router can know whether there is a multicast receiver (member)
of a specified group on the network segment to which each interface of the router is
connected. Each host stores information about only the multicast groups it joins.
At present, IGMP has three versions, IGMPv1 (defined in RFC 1112), IGMPv2 (defined in RFC
2236), and IGMPv3 (defined in RFC 3376). All IGMP versions support the Any-Source
Multicast (ASM) model. IGMPv3 can be directly applied to the Source-Specific Multicast
(SSM) model, whereas IGMPv1 and IGMPv2 require to use the SSM-Mapping technology to
support the SSM model.
2.2 IGMP Features Supported by the NE5000E

The supported IGMP features include basic IGMP functions, Router-Alert options, IGMP
querier parameter settings, and SSM mapping.
Basic IGMP Functions

The NE5000E supports the following basic IGMP functions:
l Configuration of IGMPv1, IGMPv2, or IGMPv3

l Adding of an interface to a multicast group statically
After an interface is added to a multicast group statically, the system considers that the
network segment where the interface resides contains a group member.
l Limit on the range of multicast groups to which an interface can be added
Currently, IGMPv3 supported by the NE5000E can process the following packets:
l Packets with group addresses within the SSM group address range
l Packets with group addresses within the ASM group address range
All the packets that do not match the preceding conditions are not processed.

Router-Alert Options
IGMP supports multicast packets without local receivers to be delivered to the upper-layer
protocol for processing by adding Router-Alert options to the packets.
You can determine whether to enable the NE5000E to send IGMP packets with Router-Alert
options or enable the NE5000E to accept only IGMP packets with Router-Alert options.
IGMP Querier Parameter Settings

IGMPv1 allows the setting of the interval for sending general query messages and the robustness
variable.
IGMPv2 or IGMPv3 allows the setting of the following parameters:
l Interval for sending IGMP general query messages

l IGMP robustness variable
l Maximum response time of IGMP Query messages
l Keepalive time of other IGMP queriers
l Interval for sending IGMP last-member query messages
l IGMP prompt leave feature
After receiving a Leave message for a certain multicast group, the interface enabled with
prompt leave directly deletes the records of the multicast group without sending a last-
member query message.
SSM Mapping
SSM mapping enables multicast devices to provide SSM services for user hosts that run IGMPv1
or IGMPv2.
2.3 Configuring Basic IGMP Functions

After basic IGMP functions are configured on the interfaces connecting multicast devices to the
Applicable Environment
IGMP runs on the network segment where the router is directly connected to user hosts. It must
be configured on both the router and user hosts. This section describes how to configure IGMP
on the router.
Before configuring IGMP, enable IP multicast routing. IP multicast routing is the precondition
for configuring all multicast functions. If IP multicast routing is disabled, all multicast-related
configurations are deleted.
IGMP needs to be enabled on the interfaces connected to user hosts. Specify matching IGMP
versions for the router and attached user hosts because the packet formats of IGMPv1, IGMPv2,
and IGMPv3 are different. The IGMP version at the router side must be of a higher version and
be compatible with the lower version at the host side. Other IGMP-related configurations can
be performed only after IGMP versions are specified.

In addition, by configuring interfaces on the router to statically join a multicast group, enable
the router to rapidly respond to users' requests, thereby shortening channel switching time.
To make hosts on the network segment where interfaces of the router reside join specified
multicast groups and receive multicast packets for these groups, define an ACL rule as a filter
to restrict the range of multicast groups that the hosts can join. This guarantees IGMP security.
Pre-configuration Tasks
Before configuring basic IGMP functions, complete the following tasks:
l Configuring link layer protocol parameters and IP addresses for interfaces to ensure that
the link layer protocol status of the interfaces is Up
l Configuring a unicast routing protocol to make devices routable
Configuration Procedures
Figure 2-1 Flowchart for configuring basic IGMP functions
Enable multicast routing
Enable PIM-SM
Enable IGMP
Set an IGMP version
Configure an interface to statically

join an IGMP group
Set the range of multicast groups

that an interface can join
Mandatory
procedure
Optional
procedure
2.3.1 Enabling Multicast Routing

Enabling multicast routing on the router is a prerequisite for configuring any multicast features.
Context
The configuration related to the VPN instance is only required on the PE. If the PE has a VPN
instance interface connected to the host, you must perform Steps 3 and 4.

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

Step 2 Run:
multicast routing-enable
IP multicast routing is enabled in the public network instance.
CAUTION
Running the undo multicast routing-enable command will clear all the multicast
configurations of the public network instance or the VPN instance and terminate the multicast
service running in the instance. If you want to restore the multicast service in the instance, re-
configure the related command.
Step 3 (Optional) Run:

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

ipv4-family
The IPv4 address family is enabled for the VPN instance and the VPN instance IPv4 address
family view is displayed.
route-distinguisher route-distinguisher
An RD is configured for the VPN instance IPv4 address family.

IP multicast routing is enabled in the VPN instance.

Step 7 Run:
commit
The configuration is committed.
----End
2.3.2 Enabling PIM-SM

After PIM-SM is enabled on the interface connected to other routers, the interface can establish
PIM neighbor relationships with the routers.
Procedure
Step 1 Run:
system-view

Step 2 Run:
interface interface-type interface-number
The interface view is displayed.
Step 3 Run:
pim sm
PIM-SM is enabled.
CAUTION
Running the undo pim sm command will clear PIM neighbor relationships on the interface and
terminate the multicast service running on the interface.
Step 4 Run:
commit
----End
2.3.3 Enabling IGMP

User hosts can dynamically join multicast groups after IGMP is enabled on the interfaces
connected to user network segments.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of the interface connected to a user network segment is displayed.
Step 3 Run:
igmp enable
IGMP is enabled.
Step 4 Run:
commit
----End

2.3.4 (Optional) Setting an IGMP Version

Interfaces connecting multicast devices to the same user network segment must use the same
IGMP version; otherwise, multicast devices fail to communicate with each other.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
igmp version { 1 | 2 | 3 }
An IGMP version is set for the interface.

By default, IGMPv2 is run on the interface.
Step 4 Run:
commit
----End
2.3.5 (Optional) Configuring an Interface to Statically Join an IGMP

Group
After an interface connecting the multicast device to a user network segment is configured to
statically join an IGMP group, the multicast device always considers that the interface has an
attached multicast group member and continues forwarding required multicast packets to this
interface.
Context
If a user network segment has stable hosts that demand multicast programs, configure the
interface connected to the user network segment to statically join an IGMP group This ensures
that the interface can rapidly respond to users' requests and shortens channel switching time.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
igmp static-group group-address [ inc-step-mask { group-mask | group-mask-length }
number group-number ] [ source source-address ]
The interface is configured to statically join an IGMP group.

The igmp static-group command must be run on the interfaces connected to user hosts. The
interface can statically join a single IGMP group or source/group, or multiple IGMP groups or
source/groups.
After the interface is configured to statically join an IGMP group, multicast entries generated
on the router never time out. Therefore, the router keeps forwarding multicast data to the
interface. If the interface no longer needs to receive multicast data for the group, the static IGMP
group configurations must be deleted manually from the interface.
Step 4 Run:
commit
----End
2.3.6 (Optional) Setting the Range of Multicast Groups that an

Interface Can Join
After an IGMP group policy is configured on the interfaces connected to user network segments,
user hosts can join certain IGMP groups.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
igmp group-policy { acl-number | acl-name acl-name } [ 1 | 2 | 3 ]
The range of multicast groups that the interface can join is set.
By default, hosts can join any multicast group.
Step 4 Run:
commit
----End
2.3.7 Checking the Configuration

After basic IGMP functions are configured, check the configurations and operating status of
IGMP and information about IGMP group members.

Prerequisite
All basic IGMP function configurations are complete.
Procedure
l Run the display igmp [ vpn-instance vpn-instance-name | all-instance ] interface
[ interface-type interface-number | up | down ] [ verbose ] command to view the
configurations and operating status of IGMP on an interface.
l Run the display igmp [ vpn-instance vpn-instance-name | all-instance ] group [ group-
address | interface interface-type interface-number ] * [ static ] [ verbose ] command to
view information about IGMP group members.
----End
Example
Run the display igmp interface gigabitethernet 1/0/0 command, and you can see IGMP
configurations on GE 1/0/0. For example:
<HUAWEI> display igmp interface gigabitethernet 1/0/0
Interface information of VPN-Instance: public net
Ethernet1/0/0(192.168.101.2):
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: 192.168.101.2 (this router)
Total 1 IGMP Group reported
Run the display igmp group command, and you can see information about the multicast groups
that interfaces in the public network instance dynamically join. For example:
<HUAWEI> display igmp group
Interface group report information of VPN-Instance: public net
GigabitEthernet6/0/1(10.1.6.2):
Group Address Last Reporter Uptime Expires
225.1.1.2 10.1.6.10 00:02:04 00:01:17
Run the display igmp group static command, and you can see information about the multicast
groups that interfaces in the public network instance statically join. For example:
<HUAWEI> display igmp group static
Static join group information of VPN-Instance: public net
Ethernet1/5/0:
Total 2 entries
Group Address Source Address Expires
226.0.0.1 0.0.0.0 never
226.0.0.2 0.0.0.0 never
Pos1/5/1:
Total 1 entry
226.0.0.6 0.0.0.0 never

2.4 Configuring IGMP SSM Mapping

To ensure that IGMP versions on a multicast device and user hosts are compatible and enable
the multicast device running a higher version of IGMP to provide SSM services for user hosts
running a lower version of IGMP, configure SSM mapping on the multicast device.
On a network segment providing multicast SSM services, an interface on a multicast router runs
IGMPv3 but user hosts run IGMPv1 or IGMPv2 due to some causes. To enable the multicast
router to provide SSM services for user hosts, configure SSM mapping on the router.
The SSM mapping function effectively protects multicast sources from being attacked.
Before configuring IGMP SSM mapping, complete the following tasks:
l Enable multicast routing
l 2.3 Configuring Basic IGMP Functions
Figure 2-2 Flowchart for configuring IGMP SSM mapping
Enable the SSM mapping

function
Configure IGMP SSM

mapping
Mandatory
procedure
Optional
procedure
2.4.1 Enabling SSM Mapping

Enabling the SSM mapping function on an interface connecting is a prerequisite for configuring
IGMP SSM mapping. The SSM source/group address mapping entries configured on the
interface take effect only after SSM mapping is enabled on the interface.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
igmp version 3
The IGMP version is set to 3.
To ensure that all user hosts (running any IGMP version) can obtain SSM services, IGMPv3 is
recommended.
Step 4 Run:
igmp ssm-mapping enable
The SSM mapping function is enabled.
Step 5 Run:
commit
----End
2.4.2 Configuring Static SSM Mapping

The SSM mapping function configured on a multicast device connected to a user network
segment allows user hosts that support only IGMPv1 or IGMPv2 to join specific source/groups.
It implements IGMP version compatibility on the multicast device and user hosts and enables
the multicast device to provide SSM services for all the user hosts.
Procedure
Step 1 Run:
system-view
Step 2 Run:
igmp [ vpn-instance vpn-instance-name ]
The IGMP view is displayed.
Step 3 Run:
ssm-mapping group-address { mask | mask-length } source-address
A mapping from an IGMP group to a source is created.
l group-address { mask | mask-length specifies an IGMP group address and mask. By default,
the SSM group address range is from 232.0.0.0 to 232.255.255.255. You can run the ssm-
policy command to set an SSM group address range out of this range.
l source-address specifies a multicast source address mapped to the IGMP group address.
You can run the ssm-mapping command for several times to map the same IGMP group to
multiple sources.
Step 4 Run:
commit

----End

After IGMP SSM mapping is configured, check information about the groups configured with
SSM mapping, SSM mapping rules of a specified group, and SSM mapping status to ensure
normal operating of the SSM mapping function.
Prerequisite
All IGMP SSM mapping configurations are complete.
Procedure
address | interface interface-type interface-number ] * ssm-mapping [ verbose ] command
to view details about IGMP groups configured with SSM mapping.
l Run the display igmp [ vpn-instance vpn-instance-name | all-instance ] ssm-mapping
group [ group-address ] command to view SSM mapping rules of a specified IGMP group.
interface [ interface-type interface-number ] command to check whether the SSM mapping
function is enabled on an interface.
----End
Example
Run the display igmp interface verbose command, and you can see details about IGMP
interfaces in the public network instance. The SSM-Mapping field in the command output
shows whether the SSM mapping function is enabled on an interface. For example:
<HUAWEI> display igmp interface verbose
Ethernet3/0/1(192.168.101.1):
IGMP is enabled
IGMP state: up
IGMP limit: -
Value of last member query time: 2 s
Value of last member query interval: 1 s
Value of startup query interval: 15 s
Value of startup query count: 2
General query timer expiry (hours:minutes:seconds): 00:00:44
IGMP activity: 4 joins, 0 leaves
Robustness (negotiated): -
Robustness (configured): 2
Require-router-alert: disabled
Send-router-alert: enabled

Ip-source-policy: disabled
Prompt-leave: disabled
SSM-Mapping: enabled
Startup-query-timer-expiry: off
Other-querier-present-timer-expiry: off
Total 2 IGMP Groups reported
Run the display igmp group ssm-mapping command, and you can see information about the
IGMP groups configured with SSM mapping. For example:
<HUAWEI> display igmp group ssm-mapping
IGMP SSM mapping interface group report information of VPN-Instance: public net
Limited entry of this VPN-Instance: -
Ethernet3/0/1(192.168.101.1):
Total 1 IGMP SSM-Mapping Group reported
232.0.0.1 192.168.101.1 00:00:02 00:02:08
Run the display igmp ssm-mapping group command, and you can see information about the
SSM mapping rules of a specified IGMP group. For example:
<HUAWEI> display igmp ssm-mapping group
IGMP SSM-Mapping conversion table of VPN-Instance: public net
Total 2 entries 2 entries matched
00001. (10.1.0.2, 225.1.1.0)
00002. (10.1.0.2, 239.255.255.0)
Total 2 entries matched
Run the display igmp ssm-mapping interface command, and you can see information about
the interfaces in the public network instance enabled with the SSM mapping function. For
example:
<HUAWEI> display igmp ssm-mapping interface
GigabitEthernet3/0/0(192.168.19.2)
2.5 Configuring an IGMP Router-Alert Option

In this configuration task, you can configure a device to deny all the IGMP packets without
Router-Alert options or send IGMP packets without Router-Alert options.
Generally, a device sends a packet to the routing protocol layer for processing only if the
destination IP address of the packet is the IP address of a local interface. The destination IP
address of an IGMP packet is usually a multicast address but not the address of an interface on
a multicast device and thus the IGMP packet may fail to be sent to the routing protocol layer for
processing. Router-Alert options can address such a problem. IGMP packets carrying Router-
Alert options need to be sent to the routing protocol layer for processing.
NOTE
For details about Router-Alert options, see RFC 2113.
Before configuring an IGMP Router-Alert option, complete the following tasks:


Choose one or more configuration tasks (excluding "Checking the Configuration") as needed.
2.5.1 Configuring a Multicast Device to Deny IGMP Packets

Without Router-Alert Options
If user hosts do not want to receive any IGMP packet without the Router-Alart option, the
multicast device directly connected to the user hosts can be configured to deny all the IGMP
packets without Router-Alert options.
Context
By default, the router does not check whether the received IGMP packets contain Router-Alert
options, that is, the router accepts and processes all the received IGMP packets.
You can perform configurations either globally or on an interface.
l Global configuration: takes effect on all interfaces.

l Configuration on an interface: takes precedence over the global configuration. If the
configuration on an interface is not done, the global configuration is used.
Procedure
l Global configuration
1. Run:
system-view

2. Run:

3. Run:
require-router-alert
The multicast device is configured to accept and process only the IGMP packets with
Router-Alert options and discard those without Router-Alert options.
4. Run:
commit

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

2. Run:

The view of the interface connected to a user network segment or a switching device
is displayed.
3. Run:
igmp require-router-alert
The interface is configured to accept and process only the IGMP packets with Router-
Alert options and discard those without Router-Alert options.
4. Run:
commit

----End
2.5.2 Configuring a Multicast Device to Send IGMP Packets

Without Router-Alert Options
If some IGMP interfaces on the same network need to receive IGMP packets without Router-
Alert options, configure the multicast device connected to the user network segment to send
IGMP packets without Router-Alert options.
Context
By default, the router sends IGMP packets with Router-Alert options.
Procedure
1. Run:
system-view

2. Run:

3. Run:
undo send-router-alert
The device is configured to send IGMP packets without Router-Alert options.

4. Run:
commit

1. Run:
system-view


2. Run:
is displayed.
3. Run:
undo igmp send-router-alert
The interface is configured to send IGMP packets without Router-Alert options.

4. Run:
commit

----End

After an IGMP Router-Alert option is configured, check the configurations and operating status
of IGMP to ensure normal running of IGMP.
Prerequisite
All the IGMP Router-Alert option configurations are complete.
Procedure
----End
Example
Run the display igmp interface verbose command, and you can see details about IGMP
interfaces in the public network instance. The command output shows that GE 6/0/0 denies the
received packets that do not contain Router-Alert options. For example:
Ethernet3/0/1(192.168.101.1):
IGMP is enabled
IGMP state: up
IGMP limit: -

2.6 Configuring an IGMP Querier

network segment to update group memberships. Interfaces connecting multicast devices to the
same user network segment must use the same IGMP parameters; otherwise, multicast devices
on the network fail to communicate with each other.
network segment connected to receivers. When receiving a Report message from a group
member, the querier refreshes group memberships on this network segment. If non-queriers have
not received any general query message within the Keepalive time of other IGMP queriers, they
consider the current IGMP querier faulty and trigger a new round of querier election
automatically.
In ADSL dial-up access, the IGMP querier corresponds to only one host because one host
corresponds to one port. When a receiver frequently joins or leaves multiple multicast groups,
like switching among TV channels, enable the prompt leave on the querier.
Before configuring an IGMP querier, complete the following tasks:
2.6.1 Configuring an IGMPv1 Querier

Configuring an IGMPv1 querier involves setting the interval for sending general query messages
and robustness variable.

Context
CAUTION
IGMP parameters; otherwise, multicast devices on the network fail to communicate with each
other.
IGMPv1 queriers are elected by the PIM protocol. You can configure parameters of IGMPv1
queriers either globally or on an interface.

Procedure
1. Run:
system-view

2. Run:

3. Run:
timer query interval
The interval for sending general query messages is set.
By default, the interval is 60 seconds.

4. Run:
robust-count robust-value
A robustness variable is set.
By default, the robustness variable of an IGMP querier is 2.

5. Run:
commit

1. Run:
system-view

2. Run:

3. Run:
igmp timer query interval

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

By default, the robustness variable of an IGMP querier is 2.
5. Run:
commit

----End
2.6.2 Configuring an IGMPv2/v3 Querier

Configuring an IGMPv2/v3 querier involves setting the interval for sending general query
messages, robustness variable, maximum response time of Query messages, Keepalive time of
other IGMP queriers, and interval for sending IGMP last-member query messages, and
configuring group memberships on an interface to never time out and the IGMP prompt leave
function.
Context
CAUTION
IGMP parameters; otherwise, multicast devices on the network fail to communicate with each
other.
IGMPv2/v3 queriers are elected by the IGMP protocol. You can configure parameters of
IGMPv2/v3 queriers either globally or on an interface.
NOTE
During the configuration, ensure that the interval for sending general query messages is greater than the
maximum response time of Query messages but is smaller than the Keepalive time of other IGMP queriers.
Procedure
1. Run:
system-view

2. Run:

3. Run:

4. Run:

By default, the robustness variable of an IGMP querier is 2. The greater the robustness
variable is, the longer timeout period a group has.
When the router starts, the router sends general query messages for the number of
robust-value times. The sending interval is 1/4 of the interval for sending IGMP
general query messages.
After the router receives a Leave message,
For IGMPv2, the router sends group-specific query messages for the number of
robust-value times. The sending interval is set by using the lastmember-
queryinterval command.
For IGMPv3, the router sends group-specific or group-and-source-specific query
messages for the number of robust-value times. The sending interval is set by using
the lastmember-queryinterval query command.
5. Run:
max-response-time interval
The maximum response time of IGMP Query messages is set.

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

The formula used to calculate the Keepalive time of other IGMP queriers is: Keepalive
time of other IGMP queriers = Robustness variable x Interval for sending IGMP
general query messages + 1/2 x maximum response time of IGMP Query messages.
If the robustness variable, the interval for sending IGMP general query messages, and
the maximum response time of IGMP Query messages are all of default values, the
Keepalive time of other IGMP queriers is 125 seconds.
7. Run:
lastmember-queryinterval interval
The interval for sending IGMP last-member query messages is set.

By default, the interval for sending IGMP last-member query messages is 1s. The
shorter the interval is, the more sensitive the querier is.
8. Run:
commit


1. Run:
system-view

2. Run:

3. Run:
igmp timer query interval

4. Run:
igmp max-response-time interval
The maximum response time of IGMP Query messages is set.

5. Run:
igmp timer other-querier-present interval
The Keepalive time of other IGMP queriers is set.

6. Run:
igmp robust-count robust-value

7. Run:
igmp lastmember-queryinterval interval
The interval for sending IGMP last-member query messages is set.

8. Run:
igmp prompt-leave [ group-policy { acl-number | acl-name acl-name } ]
The IGMP prompt leave function is configured on the interface.

By default, IGMP-enabled interfaces send last-member query messages after
receiving Leave messages for a specific multicast group from hosts. If the IGMP
prompt leave function is enabled, the interfaces directly delete the records of the
multicast group without sending last-member query messages.
9. Run:
commit

----End

After an IGMP querier is configured, check the configurations and operating status of IGMP to
ensure normal running of IGMP.
Prerequisite
All IGMP querier configurations are complete.

Procedure
----End
Example
Run the display igmp interface verbose command, and you can see detailed IGMP information
on an interface, including parameters of an IGMP querier. For example:
Ethernet3/0/1(192.168.101.1):
IGMP is enabled
IGMP state: up
IGMP limit: -
2.7 Maintaining IGMP

Maintaining IGMP involves resetting IGMP group information, monitoring IGMP operating
status, and debugging IGMP.
2.7.1 Clearing IGMP Group Information

After you confirm to clear IGMP group information, use the reset command in the user view.
Context
CAUTION
The reset igmp command clears information about the IGMP groups that an interface
dynamically joins, which may cause receivers to fail to receive multicast data normally. Exercise
caution when running this command.

Procedure
l To clear information about the IGMP groups that an interface dynamically joins, run the
following commands in the user view.
reset igmp [ vpn-instance vpn-instance-name | all-instance ] group { all | interface
interface-type interface-number { all | group-address [ mask { group-mask | group-
mask-length } ] [ source-address [ mask { source-mask | source-mask-length } ] ] } }
reset igmp [ vpn-instance vpn-instance-name | all-instance ] group ssm-mapping
{ all | interface interface-type interface-number { all | group-address [ mask { group-
mask | group-mask-length } ] } }
l To clear information about the IGMP groups that an interface statically joins, run the undo
igmp static-group { all | group-address [ inc-step-mask { group-mask | group-mask-
length } number group-number ] [ source source-address ] } command in the interface
view.
----End
2.7.2 Monitoring the Operating Status of IGMP

You can monitor the operating status of IGMP by viewing IGMP group information, SSM
mapping information, IGMP-enabled interface information, and IGMP routing table
information.
Context
In routine maintenance, run the following commands in any view to view the operating status
of IGMP.
Procedure
address | interface interface-type interface-number ] * [ static ] [ verbose ] command to
view IGMP group information on an interface.
address | interface interface-type interface-number ] * ssm-mapping [ verbose ] command
to view IGMP groups configured with SSM mapping.
group [ group-address ] command to view SSM mapping rules of a specified group.
----End

Configuration examples show you how to configure basic IGMP functions and how to configure
IGMP SSM mapping.

2.8.1 Example for Configuring Basic IGMP Functions

After basic IGMP functions are configured on a multicast network, user hosts can steadily receive
multicast data from multicast sources after being configured to statically join multicast groups.
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, an interface is numbered in the format of chassis ID/
slot number/card number/interface number, and a slot is numbered in the format of chassis ID/
slot number.
On the network shown in Figure 2-3, multicast services are deployed on the ISP network. An
IGP has been deployed to ensure that unicast routes are available. Hosts on this network want
to receive VOD information with the multicast service. For example, Host A and Host B want
to join multicast group 225.1.1.1 to steadily receive popular programs.
Figure 2-3 Networking diagram of configuring basic IGMP functions
Ethernet
HostA
PIM network RouterA Receiver
N1
GE1/0/0
POS2/0/0
HostB
RouterD
POS2/0/1
RouterB Leaf network
POS2/0/2 GE1/0/0
HostC
POS1/0/0 POS2/0/0 Receiver
POS2/0/3 N2
RouterC
GE1/0/0 HostD
POS2/0/0
Ethernet
Device Interface IP Address Device Interface IP Address

Router A POS 2/0/0 192.168.1.1/24 Router D POS 1/0/0 192.168.4.1/24
GE 1/0/0 10.110.1.1/24 POS 2/0/1 192.168.1.2/24
Router B POS 2/0/0 192.168.2.1/24 POS 2/0/2 192.168.2.2/2
GE 1/0/0 10.110.2.1/24 POS 2/0/3 192.168.3.2/24
Router C POS 2/0/0 192.168.3.1/24
GE 1/0/0 10.110.2.2/24

Precautions
When configuring basic IGMP functions, note the following points:
l PIM-SM and then IGMP need to be enabled on the interfaces connected to hosts.
l Interfaces connected to the same user network segment must use the same IGMP version.
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure IP addresses for interfaces on each router and configure a unicast routing
protocol.
2. Enable multicast routing on all routers that provide multicast services.
3. Enable PIM-SM on all interfaces of the multicast routers.
4. Enable IGMP on the interfaces connected to hosts.
5. Configure GE 1/0/0 on Router A to statically join IGMP group 225.1.1.1 to steadily receive
multicast data.
Data Preparation
To complete the configuration, you need the following data.
l Version numbers of IGMP run on routers and user hosts
l Address of the IGMP group that interfaces statically joins
Procedure
Step 1 Configure IP addresses for interfaces on each router and configure a unicast routing protocol.
The configuration details are not provided here.
Step 2 Enable multicast on each router and PIM-SM on each interface of the routers.
# Configurations on Routers A, B, and C are similar to those on Router D and therefore their
configuration details are not provided here.
[~RouterD] multicast routing-enable
[~RouterD] interface pos 1/0/0
[~RouterD-Pos1/0/0] pim sm
[~RouterD-Pos1/0/0] quit
[~RouterD-Pos2/0/3] commit
Step 3 Configure an RP.

# Configure a dynamic RP on Router D.
[~RouterD] pim
[~RouterD-pim] c-bsr pos 1/0/0
[~RouterD-pim] c-rp pos 1/0/0
[~RouterD-pim] commit

[~RouterD-pim] quit
Step 4 Enable IGMP on the interfaces connected to hosts.

# Configurations on Routers B and C are similar to those on Router A and therefore their
[~RouterA] interface gigabitethernet 1/0/0
[~RouterA-GigabitEthernet1/0/0] igmp enable
[~RouterA-GigabitEthernet1/0/0] commit
[~RouterA-GigabitEthernet1/0/0] quit
Step 5 Configure GE 1/0/0 on the Router A to statically join IGMP group 225.1.1.1.
[~RouterA-GigabitEthernet1/0/0] igmp static-group 225.1.1.1
Step 6 Verify the configuration.

# Run the display igmp interface command to view brief IGMP information on the interfaces
of the router. For example, IGMP information on GE 1/0/0 of Router B is as follows:
<RouterB> display igmp interface
GigabitEthernet1/0/0(10.110.2.1):
IGMP is enabled
IGMP state: up
IGMP limit: -
Value of query interval for IGMP(in seconds): 60 s
Value of other querier timeout for IGMP(in seconds): 0 s
Value of maximum query response time for IGMP(in seconds): 10 s
The command output shows that Router B is a querier. This is because GE 1/0/0 of Router B
has the lowest IP address among the interfaces connected to the user network segment.
# Run the display pim routing-table command on Router A to check whether GE 1/0/0 has
joined IGMP group 225.1.1.1 statically. If a (*, 225.1.1.1) entry is generated on Router A, the
downstream interface is GE 1/0/0, and the protocol type is static, GE 1/0/0 has joined IGMP
group 225.1.1.1 statically. The command output as follows:
<RouterA> display pim routing-table
VPN-Instance: public net
Total 1 (*, G) entry; 0 (S, G) entry
(*, 225.1.1.1)
RP: 192.168.4.1
Protocol: pim-sm, Flag: WC
UpTime: 00:12:17
Upstream interface: Pos2/0/0
Upstream neighbor: 192.168.1.1
RPF prime neighbor: 192.168.1.1
Downstream interface(s) information:
Total number of downstreams: 1
1: GigabitEthernet1/0/0
Protocol: igmp, UpTime: 00:12:17, Expires: -
----End
Configuration Files
l Configuration file of Router A

#
sysname RouterA
#
#
isis 1
network-entity 10.0000.0000.0001.00
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp static-group 225.1.1.1
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
pim sm
isis enable 1
#
return
l Configuration file of Router B
#
sysname RouterB
#
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.2.1 255.255.255.0
pim sm
isis enable 1
#
return
l Configuration file of Router C
#
sysname RouterC
#
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.3.1 255.255.255.0

pim sm
isis enable 1
#
return
l Configuration file of Router D

#
sysname RouterD
#
#
isis 1
network-entity 10.0000.0000.0004.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.4.1 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/1
undo shutdown
link-protocol ppp
ip address 192.168.1.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/2
undo shutdown
link-protocol ppp
ip address 192.168.2.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/3
undo shutdown
link-protocol ppp
ip address 192.168.3.2 255.255.255.0
pim sm
isis enable 1
#
return
2.8.2 Example for Configuring IGMP SSM Mapping

If user hosts on a network run only IGMPv1 or IGMPv2 and cannot be upgraded to IGMPv3,
SSM mapping is required to implement version compatibility between a multicast device
(running a higher IGMP version) and user hosts (running lower IGMP versions) and enable the
multicast device to provide SSM services for the user hosts. The user hosts can then receive
multicast data from a specified source.
CAUTION
slot number.

On the multicast network shown in Figure 2-4, PIM-SM is run and the SSM mode is configured
to provide multicast services. IGMPv3 is run on the interface connecting the router to the receiver
and IGMPv2 is run on the receiver. The IGMP version on the receiver is unable to be upgraded
to IGMPv3.
The SSM group address range is set to 232.1.1.0/24 on the current network and Sources 1, 2,
and 3 all send multicast data to multicast groups in this range. The receiver, however, wants to
receive multicast data only from Sources 1 and 3.
Figure 2-4 Networking diagram for configuring IGMP SSM mapping

Source2
RouterB RouterC Source3
GE1/0/0 GE3/0/0 GE3/0/0 GE1/0/0
GE2/0/0 GE2/0/0
Leaf network Leaf network
PIM-SM
Source1 DSLAM
GE2/0/0 GE2/0/0
GE1/0/0 GE1/0/0
GE3/0/0 GE3/0/0
RouterA RouterD
Leaf network
Receiver

Router A GE 1/0/0 133.133.1.2/24 Router C GE 1/0/0 133.133.3.2/24
GE 2/0/0 192.168.1.1/24 GE 2/0/0 192.168.3.1/24
GE 3/0/0 192.168.4.2/24 GE 3/0/0 192.168.2.2/24
Router B GE 1/0/0 133.133.2.2/24 Router D GE 1/0/0 133.133.4.2/24
GE 2/0/0 192.168.1.2/24 GE 2/0/0 192.168.3.2/24
GE 3/0/0 192.168.2.1/24 GE 3/0/0 192.168.4.1/24
Precautions
When configuring IGMP SSM mapping, note the following points:
l PIM-SM and then IGMP need to be enabled on the interfaces connected to hosts.
l The SSM group address ranges set on all routers in the PIM-SM domain must be consistent.
l The SSM source/group address mapping entries configured on the interface take effect only
after SSM mapping is enabled on the interface.
1. Configure IP addresses for interfaces on each router and configure a unicast routing
protocol.

2. Enable multicast routing on all routers that provide multicast services.

3. Enable PIM-SM on all interfaces of the multicast routers.
4. Enable IGMP and SSM mapping on the interface connecting the router to the receiver.
5. Set SSM group address ranges on all routers in the PIM-SM domain.
6. Configure SSM mapping rules on the router connected to the receiver.
Data Preparation
l SSM group address range
l IP addresses of Sources 1 and 3
Procedure
Step 1 Configure IP addresses for interfaces on each router and configure a unicast routing protocol.
Step 2 Enable multicast on each router and PIM-SSM on each interface of the routers.
[~RouterD] interface gigabitethernet 1/0/0
[~RouterD-GigabitEthernet1/0/0] pim sm
[~RouterD-GigabitEthernet1/0/0] quit
[~RouterD-GigabitEthernet3/0/0] commit
Step 3 Enable IGMP and SSM mapping on the interface connecting the router to the receiver.
# Enable IGMP and SSM mapping on GE 1/0/0 of Router D.
[~RouterD-GigabitEthernet1/0/0] igmp enable
[~RouterD-GigabitEthernet1/0/0] igmp version 3
[~RouterD-GigabitEthernet1/0/0] igmp ssm-mapping enable
Step 4 Set SSM group address ranges.

# Set SSM group address ranges to 232.1.1.0/24 on all routers in the PIM-SM domain. The
configurations of Routers B, C, and D are similar to those on Router A. Their configuration
details are not provided here.
[~RouterA] acl number 2000
[~RouterA-acl4-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[~RouterA-acl4-basic-2000] quit
[~RouterA] pim
[~RouterA-pim] ssm-policy 2000
[~RouterA-pim] commit
[~RouterA-pim] quit
Step 5 Configure SSM mapping rules on the router connected to the receiver.

# On Router D, map the multicast groups in the range of 232.1.1.0/24 to Sources 1 and 3.
[~RouterD] igmp
[~RouterD-igmp] ssm-mapping 232.1.1.0 24 133.133.1.1
[~RouterD-igmp] ssm-mapping 232.1.1.0 24 133.133.3.1
[~RouterD-igmp] commit
[~RouterD-igmp] quit

# View information about SSM mapping rules on Router D.
<RouterD> display igmp ssm-mapping group
IGMP SSM-Mapping conversion table of VPN-Instance: public net
00001. (133.133.1.1, 232.1.1.0)
00002. (133.133.3.1, 232.1.1.0)
# The command output shows that the receiver joins group 232.1.1.1. Then run the display igmp
group ssm-mapping command to view source/group information on router D. The command
output is as follows:
<RouterD> display igmp group ssm-mapping
IGMP SSM mapping interface group report information of VPN-Instance: public net
GigabitEthernet1/0/0 (133.133.4.2):
232.1.1.1 133.133.4.1 00:01:44 00:00:26
<RouterD> display igmp group ssm-mapping verbose
Limited entry of this VPN-Instance: -
GigabitEthernet1/0/0 (133.133.4.2):
Total entry on this interface: 1
Limited entry on this interface: -
Group: 232.1.1.1
Uptime: 00:01:52
Expires: 00:00:18
Last reporter: 133.133.4.1
Last-member-query-counter: 0
Last-member-query-timer-expiry: off
Group mode: exclude
Version1-host-present-timer-expiry: off
Version2-host-present-timer-expiry: 00:00:17
# Run the display pim routing-table command to view information about the PIM-SM routing
table on Router D. The command output is as follows:
<RouterD> display pim routing-table
Total 0 (*, G) entry; 2 (S, G) entries
(133.133.1.1, 232.1.1.1)
Protocol: pim-ssm, Flag:SG_RCVR
UpTime: 00:11:25
Upstream interface: GigabitEthernet3/0/0
Protocol: ssm-map, UpTime: 00:11:25, Expires:-
(133.133.3.1, 232.1.1.1)
UpTime: 00:11:25


Protocol: ssm-map, UpTime: 00:11:25, Expires:-
----End
Configuration Files
#
sysname RouterA
#
#
acl number 2000
rule permit source 232.1.1.0 0.0.0.255
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 133.133.1.2 255.255.255.0
pim sm
isis enable 1
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
pim sm
isis enable 1
#
undo shutdown
ip address 192.168.4.2 255.255.255.0
pim sm
isis enable 1
#
pim
ssm-policy 2000
#
return

#
sysname RouterB
#
#
acl number 2000
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 133.133.2.2 255.255.255.0
pim sm
isis enable 1
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
pim sm
isis enable 1
#

undo shutdown
ip address 192.168.2.1 255.255.255.0
pim sm
isis enable 1
#
pim
ssm-policy 2000
#
return
#
sysname RouterC
#
#
acl number 2000
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 133.133.3.2 255.255.255.0
pim sm
isis enable 1
#
undo shutdown
ip address 192.168.3.1 255.255.255.0
pim sm
isis enable 1
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
pim sm
isis enable 1
#
pim
ssm-policy 2000
#
return
#
sysname RouterD
#
#
acl number 2000
#
isis 1
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 133.133.4.2 255.255.255.0
isis enable 1
pim sm
igmp enable
igmp version 3
igmp ssm-mapping enable
#
undo shutdown
ip address 192.168.3.2 255.255.255.0
pim sm

isis enable 1
#
undo shutdown
ip address 192.168.4.1 255.255.255.0
pim sm
isis enable 1
#
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
#
pim
ssm-policy 2000
#
return

Configuration Guide - IP Multicast 3 PIM Configuration
3 PIM Configuration
About This Chapter
The PIM protocol is used to implement multicast routing and data forwarding in an AS.
3.1 PIM Overview

Protocol Independent Multicast (PIM) is an intra-domain multicast routing protocol. PIM uses
the existing unicast routing information to perform Reverse Path Forwarding (RPF) check on
multicast packets and create multicast routing entries. PIM can dynamically respond to the
changes of the network topology and maintain the multicast forwarding table.
3.2 PIM Features Supported by the NE5000E
The system supports PIM-SM and PIM-SSM. A device can run normally with default parameters
of the system. You are allowed to adjust parameters related to neighbors and forwarding
according to specific scenarios. In addition, you can configure various filtering policies to
enhance the PIM network security.
3.3 Configuring PIM-SM
In a PIM-SM network, any sender can be a multicast source and receivers cannot know the
location of multicast sources in advance. The RP is a forwarding core in the PIM-SM network.
RPs are classified into static RPs and BSR RPs, responsible for collecting multicast source
information and group member information.
3.4 Configuring a BSR Boundary
Before configuring PIM inter-domain multicast, you need to configure a BSR boundary to divide
the network into multiple PIM-SM domains. Each BSR serves only the local PIM-SM domain
and the routers outside the BSR boundary do not take part in BSR messages forwarding in this
PIM-SM domain.
3.5 Adjusting BSR RP Parameters
If a BSR RP is used, you can adjust parameters about C-RPs and C-BSRs as required and
configure a BSR administrative domain.
3.6 Configuring PIM-SSM
The PIM-SSM model provides the source-specific transmission service for receivers. It is
implemented based on some PIM-SM technologies. In PIM-SSM, there is no need for RP
mapping and a dedicated multicast forwarding path is set up directly between the source and the
receiver.

3.7 Adjusting Other PIM Parameters

You can adjust neighbor parameters, DR parameters, and forwarding parameters according to
actual networking environments.
3.8 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.
3.9 Maintaining PIM
Maintaining PIM involves resetting PIM statistics, monitoring PIM running status, and
debugging PIM.
Configuration examples are provided to tell you how to construct a basic PIM network and
configure basic functions of PIM.

3.1 PIM Overview

Protocol Independent Multicast (PIM) is an intra-domain multicast routing protocol. PIM uses
the existing unicast routing information to perform Reverse Path Forwarding (RPF) check on
multicast packets and create multicast routing entries. PIM can dynamically respond to the
changes of the network topology and maintain the multicast forwarding table.
"Protocol Independent" indicates that the unicast routing protocol that provides unicast routing
information for PIM can be a static route, Routing Information Protocol (RIP), Open Shortest
Path First (OSPF), Intermediate-System to Intermediate-System (IS-IS), or Border Gateway
Protocol (BGP). That is, multicast generates multicast routing entries based on a unicast routing
table, regardless of the type of unicast routing protocol.
PIM implements multicast packet forwarding with the help of RPF. The RPF mechanism uses
existing unicast routing information to build a Multicast Distribution Tree (MDT) on a network.
When a multicast packet reaches the router, the router performs the RPF check first.
l If the packet passes the RPF check, the router creates a multicast routing entry, and then
forwards the packet.
l If the packet does not pass the RPF check, the router directly discards the packet.
PIM Mode
PIM has three modes: PIM-SM, PIM-SSM, and PIM-DM. PIM-SM and PIM-DM use the ASM
group address range and PIM-SSM uses the SSM group address range.
l Protocol Independent Multicast Sparse Mode (PIM-SM)
The PIM-SM mode is applicable to a large-scale network with sparsely-located members.
The key mechanisms of PIM-SM are neighbor discovery, Designated Router (DR) election,
Rendezvous Point (RP) discovery, join, prune, register, and Shortest Path Tree (SPT)
switchover.
l Protocol Independent Multicast Source-Specific Multicast (PIM-SSM)
In SSM mode, users can know the exact positions of multicast sources in advance.
Therefore, users can specify the sources from which they want to receive data when they
join multicast groups. PIM-SSM adopts only some of PIM-SM technologies. It does not
need to maintain the RP, construct the RPT, or register the multicast source. An SPT can
be built directly from the source to the receiver's DR.
l Protocol Independent Multicast Dense Mode (PIM-DM)
The PIM-DM mode is applicable to a small-scale network with densely-located members.
The key mechanisms of PIM-DM are neighbor discovery, flooding, prune, graft, assert,
and status refresh.
NOTE
Currently, the NE5000E supports PIM-SM and PIM-SSM.
PIM Routing Entry

The PIM routing table records all PIM routing entries and delivers them to the multicast
forwarding table to guide the forwarding of multicast packets. In PIM, there are two types of
forwarding entries, that is, (S, G) and (*, G). S indicates the multicast source, G indicates the
multicast group, and * indicates any multicast source.

l (S, G) is applicable to the multicast packet with S being the source address and G being the
group address.
l (*, G) is applicable to the multicast packet from any source and with the group address
being G.
When a PIM router receives a multicast packet with the source address being S and the group
address being G and the packet passes the RPF check, the router forwards the packet according
to the following rules:
l If the (S, G) entry exists, the router forwards the packet according to the (S, G) entry.
l If the (S, G) entry does not exist, the router creates an (S, G) entry according to the (*, G)
entry, and then forwards the packet according to the (S, G) entry.
PIM routing entries contain such information as the multicast source address, multicast group
address, upstream interface, upstream neighbor, and downstream interface list to guide packet
forwarding. A multicast packet reaches from a unique upstream interface and is forwarded
through one or multiple downstream interfaces. Figure 3-1 displays the forwarding process of
multicast packets (with the group address being 225.1.1.1) on Router A.
Figure 3-1 Multicast packet forwarding
Source RouterB
POS2/0/0
10.1.8.1/24 10.1.2.2/24
Upstream network
segment
POS2/0/0
10.1.2.1/24 GE1/0/0 RouterC
10.1.1.1/24
RouterA
Downstream
GE3/0/0
10.1.3.1/24 network segment
Downstream
network segment
Host 2
Receiver
Host 1
Receiver
Multicast packets
Upstream interfaces
Downstream interfaces
In Figure 3-1, check the PIM routing table on Router A.

VPN-instance: public net

(10.1.8.1, 225.1.1.1)

RP: 2.2.2.2
Protocol: pim-sm, Flag: SPT ACT
UpTime: 01:35:25
Protocol: igmp, UpTime: 00:03:21, Expires: 00:03:10
Protocol: pim-sm, UpTime: 00:03:27, Expires: 00:03:15
The information used to guide packet forwarding is as follows:
l Source address: 10.1.8.1

l Group address: 225.1.1.1
l Upstream interface: POS 2/0/0; Upstream neighbor: 10.1.2.2; RPF neighbor: 10.1.2.2, that
is, Router B
l Downstream interface list: includes interfaces GE 1/0/0 and GE 3/0/0
3.2 PIM Features Supported by the NE5000E

The system supports PIM-SM and PIM-SSM. A device can run normally with default parameters
of the system. You are allowed to adjust parameters related to neighbors and forwarding
according to specific scenarios. In addition, you can configure various filtering policies to
enhance the PIM network security.
PIM-SM
l Static RP
You can configure the static RPs on all the routers in a PIM-SM domain. If there is a BSR
RP in the domain, by default, the BSR RP is preferred; however, you can configure the
static RP to be used preferentially.
l BSR RP
You can choose several routers in a PIM-SM domain and configure them as Candidate RPs
(C-RPs) and Candidate BSR (C-BSRs). Through a uniform election rule, a BSR is elected.
The BSR is responsible for collecting C-RP information and elects an RP.
l BSR boundary
You can configure a BSR boundary on the interface of the router to limit the transmission
of BSR messages and thus divide the PIM-SM domain.
l BSR administrative domain
You can configure multiple BSR administrative domains in a PIM-SM domain. Each BSR
administrative domain maintains a BSR, serving only specific multicast groups. The
multicast groups that do not belong to any BSR administrative domain belong to the global
domain. The global domain maintains a BSR, serving all the remaining multicast groups.
l C-RP and C-BSR parameter adjustment
You can adjust C-RP parameters as required, including:
Priority of a C-RP for RP election
Interval for a C-RP to send Advertisement messages
Time period for a BSR to hold the Advertisement messages received from a C-RP

ACL that defines the valid C-RP address range and the range of multicast groups served
by a C-RP
You can adjust C-BSR parameters as required, including:
Hash mask length of a C-BSR for RP calculation
Priority of a C-BSR for BSR election
Interval for a C-BSR to send BootStrap messages
Time period for a C-BSR to hold the BootStrap messages received from a BSR
ACL that defines the valid BSR address range
l Registration parameter adjustment
You can adjust parameters used when a multicast source registers with an RP as required,
including:
ACL used to filter Register messages
Method of calculating the checksum of Register messages
Holdtime of the register-suppression state
Interval for sending null Register messages
l SPT switchover conditions configuration
You can configure SPT switchover conditions and adjust the interval for checking the
forwarding rate of multicast packets.
PIM-SSM
When hosts join multicast groups, the source from which hosts want to receive data can be
specified and the SSM group address range can be configured as required.
Source Address-based Filtering

You can create an ACL for specifying the valid multicast source address range.
Neighbor Parameter Adjustment

You can adjust control parameters about PIM neighbors as required, including:
l Interval for sending Hello messages

l Time period for a neighbor to hold the reachable state
l Whether to accept the Hello messages with Generation IDs
l Priority for DR election
l Neighbor filtering function
Forwarding Parameter Adjustment

You can adjust control parameters about PIM forwarding as required, including:
l Interval for sending Join messages
l Time period for a downstream interface to hold the forwarding state
l Ttime for overriding the prune action
l Period for an interface to hold the Assert state

l Join/Prune message filtering
Multi-instance PIM
In multi-instance applications, a multicast router needs to maintain the PIM neighbor table, PIM
routing table, BSR information, and RP-set information for different VPN instances and keep
the information independent between the instances.
When the router receives a data packet, it needs to distinguish which VPN instance the packet
belongs to and forward it based on the multicast routing table of that VPN instance, or create
multicast routing entries related to that VPN instance.
PIM NSR
PIM supports non-stop routing (NSR). After this function is enabled, when the active-standby
switchover of the control plane occurs, the system can restore the services immediately, and the
control planes of its neighbors will not sense the switchover. During the active/standby
switchover of the system's control planes, the system can process new services, such as
processing new Join messages.
For details of NSR, refer to the HUAWEI NetEngine5000E Feature Description - Reliability.
PIM in Distributed Processing Mode

The PIM module has a core component responsible for calculating and maintaining routing
entries. One main control board can start multiple core components. It considers all multicast
group addresses as a set and divides the set into several subsets according to the hash result of
the multicast group addresses. Each core component bears one or multiple subsets. The service
carried by each subset is automatically allocated by the system. In this manner, multicast services
are distributed and the CPU usage and memory usage are reduced.
3.3 Configuring PIM-SM

In a PIM-SM network, any sender can be a multicast source and receivers cannot know the
location of multicast sources in advance. The RP is a forwarding core in the PIM-SM network.
RPs are classified into static RPs and BSR RPs, responsible for collecting multicast source
information and group member information.
In a large-scale network where multicast group members are sparsely located and receivers do
not need to specify multicast sources when they join multicast groups, you can configure PIM-
SM. An RP is the forwarding core on the PIM-SM network. Group members and the multicast
source converge at the RP.
l After creating an (*, G) entry according to the new IGMP member relationship, the
receiver's DR sends a Join/Prune message to the RP.
l When a multicast source starts to send data to a group, the source's DR unicasts a Register
message to the RP. After receiving the Register message, the RP decapsulates it and then
forwards the data to other multicast members along the RPT.
l RP switches traffic from the RPT to the SPT, then the RP sends a Register-Stop message
to the source's DR.

PIM-SM supports two methods for obtaining the RP.

l Static RP
Manually configure an RP on each router in the PIM-SM domain. Static RP is applicable
to small-scale PIM networks with stable topologies. For the large-scale PIM network,
configuring a static RP is complicated. To enhance the robustness and the operation
management of the multicast network, the static RP is usually used as the backup of the
dynamic RP.
l BSR RP
Select several routers in the PIM-SM domain and configure them as C-RPs and C-BSRs.
Then, an RP is automatically elected in the PIM-SM domain.
A multicast group may be in the service ranges of both the BSR RP and static RP. By default,
the router preferentially selects the BSR RP unless the static RP is configured to be preferentially
selected.
It is recommended to configure an RP to serve only one multicast group. Compared with all
groups corresponding to only one RP, this can reduce the load of a single RP and enhance the
robustness of the network.
Before configuring PIM-SM, complete the following task:
l Configuring a unicast routing protocol to ensure normal unicast routing on the network

Figure 3-2 Flowchart for configuring PIM-SM

Use a static RP Use a BSR RP
Enable multicast routing Enable multicast routing
Enable PIM-SM Enable PIM-SM
Configure a static RP Configure a BSR RP
Configure a BSR RP Configure a static RP
Set a multicast source Set a multicast source

address range address range
Adjust source Adjust source

registration parameters registration parameters
Mandatory
procedure
Optional
procedure

Context
Procedure
Step 1 Run:
system-view
Step 2 Run:

CAUTION


ipv4-family


Step 7 Run:
commit
----End

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim sm
PIM-SM is enabled.

CAUTION
Step 4 Run:
commit
----End
3.3.3 Configuring a Static RP

If you need to manually specify the location of the RP and range of multicast groups that the RP
serves, you need to configure the same static RP on all the routers in a PIM-SM domain.
Context
routers that are not configured with a static RP cannot forward multicast packets in the PIM-SM
domain.
If the network is divided into several PIM-SM domains and the static RP needs to be used, you
need to configure the same static RP on all the routers in one PIM-SM domain to specify the
range of each PIM-SM domain.
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim [ vpn-instance vpn-instance-name ]
The PIM view is displayed.

Step 3 Run:
static-rp rp-address [ basic-acl-number | acl-name acl-name ] [ preferred ]
A static RP is specified.
You can run this command repeatedly to configure multiple static RPs for the router.
l rp-address specifies the static RP address.
l basic-acl-number specifies an access control list. Such a list defines the range of the multicast
groups that the static RP serves. When the scopes of multicast groups that multiple static RPs
serve overlap, the static RP with the highest IP address acts as the RP.
l preferred indicates that the static RP takes precedence. If C-RPs are configured on the
network at the same time and preferred is set, routers prefer the statically specified RP;
otherwise, C-RPs are preferred.
Step 4 Run:
commit

----End
3.3.4 Configuring a BSR RP

Select several routers and configure them as C-BSRs and C-RPs. A BSR is elected from C-
BSRs. The BSR is responsible for collecting C-RP information and summarizing C-RP
information into an RP-set. The RP-set is then encapsulated in a BootStrap message and
advertised to all the routers in the PIM domain. According to a uniform election rule, the C-RPs
elect a BSR RP.
Context
If a network is divided into several PIM-SM domains and the BSR RP needs to be used, 3.4
Configuring a BSR Boundary is required on the interfaces of the routers at the edge of PIM-
SM domains to limit the range of each PIM-SM domain. Then, configure C-BSRs and C-RPs
in each PIM-SM domain.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 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 mask.
According to the group address G, C-RP address, and the value of hash-length, the router
calculates the hash value of the C-RPs that have the same priority and want to serve G. The
C-RP with the greatest hash value acts as the RP for G.
l priority specifies the C-BSR priority for BSR election. The greater the value, the higher the
priority.
In the BSR election, the C-BSR with the highest priority wins. In the case of the same priority,
the C-BSR with the highest IP address wins.
Step 4 Run:
c-rp interface-type interface-number [ group-policy { basic-acl-number | acl-name
acl-name } | priority priority | holdtime hold-interval | advertisement-interval
adv-interval ] *
The C-RP is configured.

l interface-type interface-number specifies the interface where the C-RP resides. The interface
must be configured with PIM-SM.

NOTE
If IP address unnumbered is enabled, it is not recommended to configure the interfaces with the same
address as C-RPs simultaneously. If the priorities of C-RPs are different, the BSR considers that the
C-RP configuration is frequently modified.
l group-policy basic-acl-number specifies that the C-RP serves only the multicast groups
matching the ACL. By default, the C-RP serves all the multicast groups.
l priority priority specifies the C-RP priority for RP election. The greater the value, the lower
the priority.
The RP election rules are as follows:
The C-RP with the longest interface address mask wins.
In case of the same interface address mask, 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.
l holdtime hold-interval specifies the timeout period for the BSR to wait for an Advertisement
message from the C-RP.
l advertisement-interval adv-interval specifies the interval for the C-RP to send
Advertisement messages.
Step 5 Run:
commit
----End
3.3.5 (Optional) Setting a Multicast Source Address Range

You can configure multicast source addresses-based filtering policies by creating ACLs. Then,
a PIM router forwards only the multicast packets whose source address or source/group
addresses match the ACLs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
source-policy { acl-number | acl-name acl-name }
The multicast source address range is set.
l If a basic ACL is created, only the multicast packets whose source addresses match the ACL
are forwarded.

l If an advance ACL is created, only the multicast packets whose source addresses and group
addresses match the ACL are forwarded.
l If the specified ACL does not exist, no multicast packets can be forwarded.
NOTE
The source-policy command is not applicable to static (S, G) entries.
Step 4 Run:
commit
----End
3.3.6 (Optional) Adjusting Source Registration Parameters

A new multicast source must register with the RP. You can configure policies of filtering Register
messages on the C-RPs and configure a device to calculate the checksum of each Register
message according to the header of the Register message. In addition, you can set the holdtime
of the register-suppression state and the interval for sending null Register messages on the
source's DR.
Context
On a PIM-SM network, the source's DR encapsulates multicast data into Register messages and
sends them to the RPs in unicast mode. The RP then decapsulates the message, and forwards
the extracted multicast data to receivers along the RPT. To prevent the attack of illegal Register
messages, you can configure the RP to accept or deny the Register messages matching certain
rules.
After the SPT switchover on the RP is complete, the multicast data reaches the RP along the
source tree in multicast mode. The RP then sends a Register-Stop message to the source's DR.
The source's DR stops sending Register messages and enters the register-suppression state.
During the register-suppression period, the DR periodically sends a Probe message (null Register
message) to notify the RP that the multicast source is still in the active state. After the register-
suppression period expires, the DR resends Register messages.
The router can work normally with default control parameters. You are allowed to adjust
registration parameters according to the specific networking environment.
NOTE
If there is no special requirement for the network, default parameters are recommended.
Procedure
l Controlling the receiving of Register messages on the C-RP
1. Run:
system-view

2. Run:

3. Run:

register-policy { advanced-acl-number | acl-name acl-name }
The policy of filtering Register messages is created.
If the (S, G) information carried in the Register message is denied by the ACL or
the ACL does not define the operation on this message, the RP discards the Register
message and hence the multicast source cannot register with the RP.
If the specified ACL does not exist, the RP denies all the received Register
messages and hence no multicast sources can register with the RP.
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. The RP

discards any Register message with an incorrect checksum.
5. Run:
commit

l Controlling register suppression on the source's DR
1. Run:
system-view

2. Run:

3. Run:
register-suppression-timeout interval
The holdtime of the register-suppression state is set.
By default, the holdtime of the register-suppression state of the source's DR is 60

seconds.
If interval is set to a smaller value, the RP receives burst multicast data more
frequently.
If interval is set to a greater value, when the (S, G) entry on the RP times out, the
delay for new receivers to join the multicast group is prolonged.
4. Run:
probe-interval interval
The interval for sending Probe messages (null Register messages) is set.
By default, the interval for the source's DR to send Probe messages to the RP is 5s.
5. Run:
commit
----End

3.3.7 (Optional) Configuring SPT Switchover Conditions

PIM-SM allows the RP or the receiver's DR to trigger the SPT switchover when the rate of
multicast packets is high. You can configure SPT switchover conditions and set the interval for
checking the forwarding rate of multicast packets on the receiver's DR.
Context
In PIM-SM forwarding, each multicast group corresponds to an RPT only. At first, all multicast
sources encapsulate data in Register messages, and send the messages to the RP in unicast mode.
The RP decapsulates the messages and forwards the data along the RPT.
Forwarding multicast data along an RPT has the following disadvantages:
l The source's DR and the RP need to encapsulate and decapsulate messages.
l The forwarding path may not be the shortest path from the source to receivers.
l Heavy data traffic increases the load of the RP, which may cause a fault.
The detailed solutions to this problem are as follows:
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's DR to the RP. The subsequent multicast packets are directly
transmitted along this path.
l SPT switchover triggered by the receiver's DR
The receiver's DR checks the forwarding rate of multicast data. If finding that the rate
exceeds the threshold, the receiver's DR triggers the SPT switchover immediately. The
receiver's DR then sends a Join message to the source and establishes a multicast route
along the shortest path from the source's DR to the receiver's DR. The subsequent packets
are forwarded along this path.
By default, the RP performs the SPT switchover after receiving the first Register message and
the receiver's DR performs the SPT switchover after receiving the first multicast data packet.
The router can work normally with default control parameters. You are allowed to adjust STP
switchover parameters according to the specific networking environment.
NOTE
If there is no special requirement for the network, default values are recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
spt-switch-threshold { traffic-rate | infinity } [ group-policy { basic-acl-number
| acl-name acl-name } [ order order-value ] ]
SPT switchover conditions are configured.

NOTE
This command takes effect only on every router that may function a receiver's DR. It does not take effect
on the RP.
l traffic-rate specifies the rate threshold of the multicast data at which the receiver's DR triggers
the SPT switchover.
NOTE
After traffic-rate is specified, Step 4 is required.

l infinity indicates that the receiver's DR never triggers the SPT switchover. Thus, multicast
data can be transmitted to the receiver only along the RPT.
l group-policy basic-acl-number specifies the range of the multicast groups to which the set
rate threshold is applicable. By default, the set threshold is applicable to all multicast groups.
l order order-value is used to adjust the order of the ACLs in the group-policy list. If a group
matches multiple ACLs, the threshold is selected in the order specified by order-value.

timer spt-switch interval
The interval for checking the forwarding rate of multicast packets is set.
Step 5 Run:
commit
----End

After PIM-SM is configured successfully, you can check information about the BSR, RP, PIM
interface, PIM neighbor, and PIM routing table through commands.
Prerequisite
All configurations of PIM-SM are complete.
Procedure
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] bsr-info command
to check information about the BSR in the PIM-SM domain.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] interface
[ interface-type interface-number ] [ verbose ] command to check information about the
PIM interface.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] neighbor
[ interface interface-type interface-number | neighbor-address | verbose ] * command to
check information about the PIM neighbor.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] routing-table
[ group-address [ mask { group-mask-length | group-mask } ] ] [ source-address [ mask
{ source-mask-length | source-mask } ] ] [ outgoing-interface include { interface-type
interface-number | register | none } ] [ fsm ] command to check information about the PIM
routing table.

l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] rp-info [ group-

address ] command to check information about the RP in the PIM-SM domain.
----End
Example
Run the display pim bsr-info command, and you can view "Elected BSR Address" and
"Candidate BSR Address" in the command output and the "State" field is displayed as "Elected",
indicating that the C-BSR is elected as a BSR. For example:
<HUAWEI> display pim bsr-info
Elected AdminScope BSR Count: 0
Elected BSR Address: 10.1.2.2
Priority: 0
Hash mask length: 30
State: Elected
Scope: Not scoped
Uptime: 00:10:42
Next BSR message scheduled at: 00:00:31
C-RP Count: 1
Candidate AdminScope BSR Count: 0
Candidate BSR Address: 10.1.2.2
Priority: 0
State: Elected
Scope: Not scoped
Wait to be BSR: 0
Run the display pim interface command, and you can view that the PIM status of the interface
is Up and view the number of PIM neighbors on the interface. For example:
<HUAWEI> display pim interface
Interface State NbrCnt HelloInt DR-Pri DR-Address
GE1/3/0 up 1 30 1 10.1.1.2
GE1/3/1 up 0 30 1 172.168.0.2 (local)
GE1/3/2 up 1 30 1 20.1.1.2
Loopback0 up 0 30 1 1.1.1.1 (local)
Run the display pim neighbor command, and you can view the number of PIM neighbors, PIM
neighbor addresses, and interfaces that set up PIM neighbor relationships. For example:
<HUAWEI> display pim neighbor
Total Number of Neighbors = 2
Neighbor Interface Uptime Expires Dr-Priority BFD-Session
10.1.1.2 GE1/3/0 02:50:49 00:01:31 1 N
20.1.1.2 GE1/3/2 02:49:39 00:01:42 1 N
Run the display pim routing-table command, and you can view source addresses and group
addresses of PIM entries and information about the RP, upstream interface, and downstream
interface. For example:
<HUAWEI> display pim routing-table

(172.168.0.12, 227.0.0.1)
RP: 2.2.2.2
Protocol: pim-sm, Flag: SPT LOC ACT
UpTime: 02:54:43
Upstream neighbor: NULL

RPF prime neighbor: NULL

Run the display pim rp-info command, and you can view the RP address, RP priority, and
addresses of the groups that the RP serves. "local" indicates that the local router is selected as
an RP. For example:
<HUAWEI> display pim rp-info
PIM-SM BSR RP information:
Group/MaskLen: 224.0.0.0/4
RP: 2.2.2.2 (local)
Priority: 0
Uptime: 03:01:36
Expires: 00:02:29
3.4 Configuring a BSR Boundary

Before configuring PIM inter-domain multicast, you need to configure a BSR boundary to divide
the network into multiple PIM-SM domains. Each BSR serves only the local PIM-SM domain
and the routers outside the BSR boundary do not take part in BSR messages forwarding in this
PIM-SM domain.
After a BSR boundary is configured on the interface of the router at the edge of a PIM-SM
domain, BootStrap messages cannot pass through this interface. The interfaces configured with
BSR boundaries divide the network into different PIM-SM domains.
In addition, BSR boundaries can be used to isolate the PIM-SM domains from the Internet.
Before configuring a BSR boundary, complete the following tasks:
l Enabling multicast routing on all routers and enable PIM-SM on all the interfaces
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of the interface on the router at the edge of the PIM-SM domain is displayed.
Step 3 Run:
pim bsr-boundary [ incoming ]
A BSR boundary is configured. BSR messages cannot cross the BSR boundary.

If incoming is specified, it indicates that the local PIM-SM domain can send BSR messages to
all the other PIM-SM domains but cannot receive BSR messages from other PIM-SM domains.
By default, all PIM-SM routers on the network can receive BSR messages.
Step 4 Run:
commit
----End
Checking the Configuration

Run the display pim [ vpn-instance vpn-instance-name | all-instance ] bsr-info command to
check information about the BSR in each PIM-SM domain.
Follow-up Procedure
1. 3.3.4 Configuring a BSR RP for each PIM-SM domain
2. Setting up MSDP peer relationships between RPs in PIM-SM domains and 4.3
Configuring PIM-SM Inter-domain Multicast
3.5 Adjusting BSR RP Parameters

If a BSR RP is used, you can adjust parameters about C-RPs and C-BSRs as required and
configure a BSR administrative domain.
At first, each C-BSR considers itself as a BSR and sends BootStrap messages carrying the C-
BSR addresses and C-BSR priorities on the entire network. Each router receives the BootStrap
messages sent by all the C-BSRs. The router then compares these messages and elects a BSR.
All routers use the same election rule and therefore the elected BSRs are the same.
All routers on the network must know the BSR address. C-RPs send Advertisement messages
to the BSR. An Advertisement message carries the C-RP address, the range of multicast groups
the C-RP serves, and the C-RP priority. The BSR summarizes these information into an RP-set,
encapsulates the RP-set in a BootStrap message, and advertises the message to all the other
routers on the network. Based on the RP-set, each router calculates routes by using the same
rule and elects the RP of this group from the multiple C-RPs to which a specific group
corresponds.
The router can work normally with default control parameters. You are allowed to adjust BSR
RP parameters according to the specific networking environment.
NOTE
Before adjusting BSR RP parameters, complete the following tasks:

l Configuring PIM-SM and using the BSR RP
You can choose to perform some of the following configuration tasks (except "Checking the
Configuration") according to the applicable environment.
3.5.1 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 router configured as a C-RP.
Context
RP election rules are as follows:
l The C-RP with the longest interface address mask wins.
l The C-RP with the highest priority wins.
l In case of the same priority, hash functions are run. The C-RP with the greatest calculated
value wins.
l If all the preceding factors are the same, the C-RP with the highest address wins.
Procedure
Step 1 Run:
system-view

Step 2 Run:

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

The greater the value, the lower the priority. By default, the global priority of the C-RP is 0.
Step 4 Run:
c-rp advertisement-interval interval
The interval for the C-RP to send Advertisement messages is set.

Step 5 Run:
c-rp holdtime interval
The time period for the BSR to hold the Advertisement messages received from the C-RP is set.
NOTE
This time period must be longer than the interval for the 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 and starts
a timer. If the BSR receives no Advertisement messages within the Holdtime, the BSR considers
the C-RP invalid or unavailable.
By default, the BSR holds the Advertisement messages received from the C-RP for about 150
seconds.
Step 6 Run:
commit
----End
3.5.2 Setting a Legal C-RP Address Range

You can create ACL rules on all C-BSRs for filtering C-RP addresses and the addresses of groups
that C-RPs serve. A BSR accepts the Advertisement messages and adds C-RP information to
the RP-set only when C-RP addresses and the addresses of the groups that C-RPs serve in the
Advertisement messages are within the legal address range. Thus, the C-RP spoofing is avoided.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
crp-policy { advanced-acl-number | acl-name acl-name }
The legal C-RP address range and the range of groups that C-RPs serve are limited.
l If C-RP addresses or the addresses of the groups that the C-RPs serve carried in the
Advertisement messages are denied by the ACL or the ACL does not define the operation
on the messages, the BSR discards the Advertisement message and hence C-RP information
is not added to the RP-Set.
l If no ACL rule corresponding to the specified advanced-acl-number exists, the BSR also
denies all the Advertisement messages and C-RP information is not added to the RP-Set.
By default, the BSR does not check the C-RP addresses and the addresses of the groups that the
C-RPs serve carried in the received Advertisement message. Thus, all the Advertisement
messages are accepted.
Step 4 Run:
commit
----End

3.5.3 Adjusting C-BSR Parameters

At first, each C-BSR considers itself as a BSR and sends BootStrap messages to all the other
routers on 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 router configured as a C-BSR.
Context
BSR election rules are as follows:
l The C-BSR with the highest priority wins.

l In case of the same priority, the C-BSR with the highest IP address wins.
Based on the result of the BSR election, a C-BSR performs one of the following operations:
l If the C-BSR wins, it periodically sends BootStrap messages to routers on the network. The
BootStrap messages carry the IP addresses of the C-BSRs and the RP-set information.
l If the C-BSR fails in the election, the C-BSR is suppressed from sending BootStrap
messages.
l When the current BSR becomes faulty, the C-BSRs automatically trigger a new round of
BSR election to prevent service interruption.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
c-bsr hash-length hash-length
The global hash mask length of the C-BSR is set.
The hash mask length carried in a BootStrap message is used for RP calculation. By default, the
global hash mask length of the C-BSR is 30.
Step 4 Run:
c-bsr priority priority
The global priority of the C-BSR is set.
The greater the value, the higher the priority. By default, the global priority of the C-BSR is 0.
Step 5 Run:
c-bsr interval interval
The interval for the C-BSR to send BootStrap messages is set.
By default, the interval for the C-BSR to send BootStrap messages is 60 seconds.

Step 6 Run:
c-bsr holdtime interval
The holdtime of the BootStrap messages received by the router from the BSR is set.
NOTE
The holdtime of the BootStrap messages received by the router from the BSR must be longer than the
interval for the C-BSR to send BootStrap messages. Otherwise, the BSR election may be unstable.
The BSR periodically sends a BootStrap message to the routers on the network. After receiving
the BootStrap message, the routers hold the message for a certain time period. During the period,
BSR election stops temporarily. If this period expires, a new round of BSR election is triggered
among C-BSRs.
By default, the router holds the BootStrap message received from the BSR for 130 seconds.
Step 7 Run:
commit
----End
3.5.4 Setting a Legal BSR Address Range

You can create ACL rules on all devices to filter BSR addresses. The devices then receive only
the BootStrap messages with the source addresses being in the valid BSR address range. Thus,
BSR spoofing is avoided.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
bsr-policy { basic-acl-number | acl-name acl-name }
A legal BSR address range is set.
l If the source addresses carried in the BootStrap messages are denied by the ACL or the ACL
does not define the operation on the messages, the routers discard the BootStrap messages.
l If no ACL rule corresponding to the specified basic-acl-number exists, the routers also deny
all the BootStrap messages.
By default, the routers do not check the source addresses of BootStrap messages. That is, the
routers consider all the received BootStrap messages legal.
Step 4 Run:
commit

----End
3.5.5 Configuring a BSR Administrative Domain

By dividing a PIM-SM network into multiple BSR administrative domains and a global domain,
the workload of a single BSR is reduced and private group addresses can be used for providing
special services for users in specific domains.
Context
By default, one PIM-SM domain has only one BSR to manage the entire domain.
To manage networks effectively, you need to configure multiple BSR administrative domains
in a PIM-SM network. Each BSR administrative domain maintains only one BSR that serves a
multicast group within a specific address range. The multicast group that does not belong to any
BSR administrative domain belongs to the global domain. The global domain maintains a BSR
that serves the other multicast groups.
NOTE
You can adjust the hash mask length and priority of the C-BSR as required:
l Global configuration: See 3.5.3 Adjusting C-BSR Parameters. The global value takes effect in both
the global domain and BSR administrative domains.
l BSR administrative domain configuration: The configuration for the BSR administrative domain takes
precedence over the global configuration. If the configuration for the BSR administrative domain is
not done, the global configuration is used.
l Global domain configuration: The configuration for the global domain takes precedence over the global
configuration. If the configuration for the global domain is not done, the global configuration is used.
Procedure
Step 1 Enabling the BSR administrative domain function on all routers
1. Run:
system-view

2. Run:

3. Run:
c-bsr admin-scope
The BSR administrative domain function is enabled.

4. Run:
commit

Step 2 Setting the ranges of multicast groups that C-BSRs in the BSR administrative domain serve and
adjusting the hash mask lengths and priorities of the C-BSRs in the BSR administrative domain
on all C-BSRs
1. Run:

system-view

2. Run:

3. Run:
c-bsr group group-address { mask | mask-length } [ hash-length hash-length |
priority priority ] *
The range of the multicast groups that a C-BSR in the BSR administrative domain serves
is set and the hash mask length and priority of the C-BSR in the BSR administrative domain
are adjusted.
group-address { mask | mask-length } specifies the range of the multicast groups that the
C-BSR in the BSR administrative domain serves. The valid multicast groups range from
239.0.0.0 to 239.255.255.255. The ranges of multicast groups that C-BSRs in different BSR
administrative domains serve can overlap. The multicast group takes effect only in the local
administrative domain, that is, a private multicast group address is used.
4. Run:
commit
Step 3 (Optional) Adjusting the hash mask lengths and priorities of all the C-BSRs in the global domain
1. Run:
system-view

2. Run:

3. Run:
c-bsr global [ hash-length hash-length | priority priority ] *
The hash mask length and priority of a C-BSR in the global domain are adjusted.
4. Run:
commit
----End

After BSR RP parameters are adjusted, you can run commands to view BSR and RP information.
Prerequisite
C-BSR parameters are adjusted as required.

Procedure
to check information about the BSR in the PIM-SM domain.
address ] command to check information about the RP in the PIM-SM domain.
----End
Example
Run the display pim bsr-info command, and you can view information about the elected BSR.
For example:
<HUAWEI> display pim bsr-info
Priority: 0
State: Accept Preferred
Scope: Not scoped
Uptime: 00:10:42
C-RP Count: 1
Priority: 0
State: Elected
Scope: Not scoped
Wait to be BSR: 0
Run the display pim rp-info command, and you can view information about the RP address,
RP priority, and addresses of the groups that the RP serve. For example:
<HUAWEI> display pim rp-info
RP: 2.2.2.2 (local)
Priority: 0
Uptime: 03:01:36
Expires: 00:02:29
3.6 Configuring PIM-SSM

The PIM-SSM model provides the source-specific transmission service for receivers. It is
implemented based on some PIM-SM technologies. In PIM-SSM, there is no need for RP
mapping and a dedicated multicast forwarding path is set up directly between the source and the
receiver.
PIM-SSM adopts some PIM-SM technologies. In PIM-SSM, there is no need for RP mapping,
RPT construction, or multicast source registration. In PIM-SSM, the DR is valid only on the
shared network segment connected with group members. After knowing the requirements of
users, the receiver's DR sends a Join message to the multicast source. The Join message is sent
upstream hop by hop and (S, G) entries are created correspondingly. As a result, an SPT from
the router directly connected to the source to the receiver's DR is set up.

The SSM model is applicable when the following conditions are met:
l The multicast group that users join is in the SSM group address range.
l Users specify the sources when joining a multicast group.
l PIM-SM is run between routers.
A network can adopt the PIM-SM and PIM-SSM models simultaneously to provide multicast
services for hosts. PIM-SM, including the RP, is configured on the network and the SSM group
address range is adjusted as required. If the groups that hosts join are beyond the SSM group
address range, PIM-SM implements multicast data forwarding.
Before configuring PIM-SSM, complete the following task:
Figure 3-3 Flowchart for configuring PIM-SSM
Enable multicast routing
Enable PIM-SM
Set an SSM group

address range
Set a multicast source address

range
Mandatory
procedure
Optional
procedure

Context
Procedure
Step 1 Run:
system-view


Step 2 Run:
CAUTION


ipv4-family


Step 7 Run:
commit
----End

Procedure
Step 1 Run:
system-view

Step 2 Run:


Step 3 Run:
pim sm
PIM-SM is enabled.
CAUTION
Step 4 Run:
commit
----End
3.6.3 Setting an SSM Group Address Range

PIM-SSM and PIM-SM have different group address ranges. If the group a host joins is in the
SSM group address range, PIM-SSM is adopted for multicast data forwarding; otherwise, PIM-
SM is adopted. The default SSM group address range is 232.0.0.0/8. You can modify the SSM
group address range.
Context
CAUTION
Ensure that the SSM group address ranges of all routers on the network are identical. Otherwise,
faults may occur on the network.
Procedure
Step 1 Run:
system-view

Step 2 Run:

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

Step 4 Run:
commit

----End
3.6.4 (Optional) Setting a Multicast Source Address Range

You can configure multicast source addresses-based filtering policies by creating ACLs. Then,
a PIM router forwards only the multicast packets whose source address or source/group
addresses match the ACLs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
source-policy { acl-number | acl-name acl-name }
The multicast source address range is set.
l If a basic ACL is created, only the multicast packets whose source addresses match the ACL
are forwarded.
l If an advance ACL is created, only the multicast packets whose source addresses and group
addresses match the ACL are forwarded.
l If the specified ACL does not exist, no multicast packets can be forwarded.
NOTE
The source-policy command is not applicable to static (S, G) entries.
Step 4 Run:
commit
----End

After PIM-SSM is configured successfully, you can check information about the PIM interface,
PIM neighbor, and PIM routing table through commands.
Prerequisite
All configurations of PIM-SSM are complete.

Procedure
[ interface-type interface-number ] [ verbose ] command to check information about the
PIM interface.
[ interface interface-type interface-number | neighbor-address | verbose ] * command to
routing table.
----End
Example
GE1/3/0 up 1 30 1 10.1.1.2
GE1/3/1 up 0 30 1 172.168.0.2 (local)
GE1/3/2 up 1 30 1 20.1.1.2
10.1.1.2 GE1/3/0 02:50:49 00:01:31 1 N
20.1.1.2 GE1/3/2 02:49:39 00:01:42 1 N
addresses of PIM entries and information about the upstream interface and downstream interface
list. For example:

(10.110.1.1, 232.1.1.1)
Protocol: pim-ssm, Flag: LOC
UpTime: 00:02:13
1: Pos1/0/0
Protocol: pim-ssm, UpTime: 00:02:13, Expires: 00:03:17

3.7 Adjusting Other PIM Parameters

You can adjust neighbor parameters, DR parameters, and forwarding parameters according to
actual networking environments.
The router can work normally with default control parameters. You are allowed to adjust
neighbor parameters, DR parameters, and forwarding parameters according to specific
networking environments.
NOTE
Before adjusting other PIM parameters, complete the following tasks:
l Configuring PIM-SM or configuring PIM-SSM
3.7.1 Adjusting 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.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
source-lifetime interval
The lifetime of a source is configured.
After receiving a multicast packet from S, the router resets the timer. If the timer times out, the
(S, G) entry is considered invalid.

Step 4 Run:
commit
----End
3.7.2 Adjusting Neighbor Parameters

Devices establish neighbor relationships by exchanging Hello messages. PIM neighbor
parameters include the interval for sending Hello messages, timeout period of the neighbor
relationship, whether to deny the Hello messages without Generation IDs, and neighbor filtering
policies.
Context
You can set the interval for sending Hello messages and timeout period of the neighbor
relationship either globally or on an interface.

l Interface-specific configuration: takes precedence over the global configuration. If no
interface-specific configurations are done, the global configuration is used.
Procedure
1. Run:
system-view

2. Run:

3. Run:
timer hello interval
The interval for sending Hello messages is set.
By default, the router sends Hello messages every 30 seconds.

4. Run:
hello-option holdtime interval
The timeout period of the neighbor relationship is set. If the local router fails to receive
any Hello message from a neighbor after the timeout period expires, it considers that
the neighbor is unreachable.
NOTE
The interval for the router to send Hello messages must be shorter than the timeout period of
the neighbor relationship.
By default, the timeout period of the neighbor relationship is 150 seconds.

5. Run:
commit


1. Run:
system-view

2. Run:
The PIM interface view is displayed.

3. Run:
pim timer hello interval
The interval for the interface to send Hello messages is set.

By default, aninterface sends Hello messages every 30 seconds.
4. Run:
pim hello-option holdtime interval
The timeout period of the neighbor relationship on the interface is set. If the local
router fails to receive any Hello message from a neighbor after the timeout period
expires, the local router considers that the neighbor is unreachable.
NOTE
The interval for the interface to send Hello messages must be shorter than the timeout period
of the neighbor relationship.
By default, the timeout period of the neighbor relationship on an interface is 150

seconds.
5. Run:
pim require-genid
The interface is configured to accept only the Hello messages with Generation ID
fields.
After an interface on the router is enabled with PIM-SM, the router generates a random
number as the Generation ID of the Hello message. If the status of the router changes,
a new Generation ID is generated. If the router finds that the Hello messages received
PIM neighbors carry different Generation IDs, it considers that the PIM neighbor
status changes.
By default, the router accepts the Hello messages without Generation ID fields.
6. Run:
pim neighbor-policy { basic-acl-number | acl-name acl-name }
A neighbor filtering policy is configured.

The neighbor filtering policy defines the range of valid neighbor addresses. The
router discards the Hello messages received from the routers beyond this address
range.
7. Run:
commit

----End

3.7.3 Adjusting DR Parameters

A source's DR is responsible for sending Register messages to an RP and a receiver's DR is
responsible for sending Join messages to an RP. routers elect a DR by exchanging Hello
messages. The router with the highest priority wins the election. In the case of the same priority,
the router with the highest IP address wins the election.
Context
In PIM-SM, a DR need be elected on the shared network segment to process the registration of
the local multicast source and group join requests of receivers. DR election is based on priorities
and IP addresses. The routers elect DR by exchanging Hello messages carrying the priorities of
themselves.
l On the shared network segment where all routers support the Hello messages carrying DR
priorities, the interface on the router with the highest DR priority is selected as the DR. In
the case of the same priority, the interface with the highest IP address acts as the DR.
l If any one of the routers does not support the Hello message carrying the DR priority, the
interface with the highest IP address acts as the DR.
You can set the DR priority either globally or on an interface.

interface-specific configuration is done, the global configuration is used.
Procedure
1. Run:
system-view

2. Run:

3. Run:
hello-option dr-priority priority
The priority for DR election is set for all the interfaces on the router.
The greater the value, the higher the priority. By default, the priority for DR election
is 1.
4. Run:
commit

1. Run:
system-view

2. Run:

3. Run:
pim hello-option dr-priority priority
The priority for DR election is set for the interface.
The greater the value, the higher the priority. By default, the priority for DR election
for an interface is 1.
4. Run:
commit
----End
3.7.4 Adjusting Forwarding Parameters

The parameters associated with PIM forwarding include the interval for sending Join/Prune
messages, holdtime of Join/Prune messages, filtering policies of Join/Prune messages, and lan-
delay and override-interval of Hello messages.
Context
A multicast router sends Join messages upstream to require to forward multicast data and Prune
messages upstream to require to stop the forwarding of multicast data.
l When the first member of a group appears, the router sends a Join message through the
upstream interface to require the upstream router to forward multicast packets to this
network segment.
On a PIM-SM network, the router periodically sends Join messages to prevent the RPT
branch from being deleted because of timeout.
l When the last member of a group leaves its group, the router sends a Prune message through
the upstream interface to request the upstream router to perform the prune action. After
receiving the Prune message, the upstream router stops forwarding packets to this network
segment. If other downstream routers exist on this network segment, they must send the
Join message to override the prune action.
A Hello message carries the lan-delay and override-interval.
lan-delay indicates the delay in transmitting Prune messages on a shared network
segment.
override-interval indicates the period allowed for overriding the Prune action. If the
routers still need to receive the multicast data, they must send Join messages upstream
within the override-interval.
The Prune-Pending Timer (PPT) equals the value of the lan-delay plus the override-interval.
PPT indicates the period from the time when the router receives a Prune message from the
downstream interface to the time when the prune action is performed. If the downstream
interface receives a Join message within the PPT, the prune action is cancelled.
You can set forwarding parameters either globally or on an interface.
l Global configuration: It is valid on each interface.


Procedure
1. Run:
system-view

2. Run:

3. Run:
timer join-prune interval
The interval for all the interfaces on the router to send Join/Prune messages is set.
By default, all the interfaces on the router send Hello messages every 60 seconds.
4. Run:
holdtime join-prune interval
The holdtime carried in the Join/Prune messages to be sent by all the interfaces on the
router is set.
An upstream router determines the period for a downstream interface to hold the join
or prune state based on the holdtime carried in the Join/Prune message received from
the downstream interface.
Commonly, the holdtime is 3.5 times longer than the interval for all the interfaces to
send Join/Prune messages. By default, the holdtime carried in the Join/Prune messages
to be sent by all the interfaces on the router is 210 seconds.
5. Run:
hello-option lan-delay interval
The lan-delay carried in the Hello messages to be sent by all the interfaces on the
router is set.
When the values of lan-delay on all the interfaces of the routers on the shared network
segment are different, the maximum value of these values is used after negotiation.
By default, the lan-delay carried in the Hello messages to be sent by all the interfaces
on the router is 500 milliseconds.
6. Run:
hello-option override-interval interval
The override-interval carried in the Hello messages to be sent by all the interfaces on
the router is set.
When the values of override-interval on all the interfaces of the routers on the shared
network segment are different, the maximum value of these values is used after
negotiation. By default, the override-interval carried in the Hello messages to be sent
by all the interfaces on the router is 2500 milliseconds.
7. 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.
8. Run:
commit

1. Run:
system-view

2. Run:

3. Run:
pim timer join-prune interval
The interval for the interface to send Join/Prune messages is set.

By default, the interface sends Join/Prune messages every 60 seconds.
4. Run:
pim holdtime join-prune interval
The holdtime carried in the Join/Prune messages to be sent by the interface is set.
By default, the holdtime carried in the Join/Prune messages to be sent by an interface
is 210 seconds.
5. Run:
pim hello-option lan-delay interval
The lan-delay carried in the Hello messages to be sent by the interface is set.
By default, the lan-delay carried in the Hello messages to be sent by an interface is
500 milliseconds.
6. Run:
pim hello-option override-interval interval
The override-interval carried in the Hello messages to be sent by the interface is set.
By default, the override-interval carried in the Hello messages to be sent by an
interface is 2500 milliseconds.
7. Run:
pim join-policy { { advanced-acl-number | acl-name acl-name } | asm
{ basic-acl-number | acl-name acl-name } | ssm { advanced-acl-number | acl-
name acl-name } }
The policy for filtering join information in Join/Prune messages is created.

The router filters join information in Join/Prune messages based on source addresses
or source/group addresses.
8. Run:
commit

----End
3.7.5 Adjusting Assert Parameters

When multiple multicast data forwarders exist on a shared network segment, the routers elect a
unique forwarder through the Assert mechanism. The router that fails in the election prevents
its downstream interface from forwarding multicast data within the holdtime of the Assert state.
After the holdtime of the Assert state expires, the downstream interface can forward multicast
data.
Context
When the following condition is met, it indicates that other multicast forwarders exist on the
network segment.
The interface that receives the multicast packet is a downstream interface in the (S, G) entry on
the local router.
When the router receives an Assert message from another multicast forwarder on the network
segment through the downstream interface at the same time when it sends an Assert message
through this interface, the router compares its own condition with the information carried in the
received Assert message for Assert election.
l If the router wins, the downstream interface retains the forwarding state and continues (S,
G) forwarding on the network segment. In this case, the downstream interface is called an
Assert winner.
l If the router fails, the downstream interface is prohibited from forwarding multicast packets
and deleted from the downstream interface list of the (S, G) entry. In this case, the
downstream interface is called an Assert loser.
All Assert losers can periodically restore multicast packet forwarding, leading to periodical
Assert election.
You can set the holdtime of the Assert state either globally or on an interface.

Procedure
1. Run:
system-view

2. Run:

3. Run:
holdtime assert interval

The period for all the interfaces on the router to hold the Assert state is set.
4. Run:
commit

1. Run:
system-view

2. Run:

3. Run:
pim holdtime assert interval
The period for the interface to hold the Assert state is set.
4. Run:
commit

----End

After PIM neighbor parameters, DR parameters, forwarding parameters, or Assert parameters
are adjusted, you can check information about the PIM interface, PIM neighbor, and PIM routing
table and statistics about PIM control messages by running commands.
Prerequisite
PIM neighbor parameters, DR parameters, forwarding parameters, or Assert parameters are
adjusted as required.
Procedure
[ interface-type interface-number | up | down ] [ verbose ] command to check information
about the PIM interface.
[ neighbor-address | interface interface-type interface-number | verbose ] * command to
routing table.
l Run the display pim control-message counters [ message-type { assert | bsr | crp |
hello | join-prune | probe | register | register-stop } ] command to check statistics about
PIM control messages.
----End

Example
GE1/3/0 up 1 30 1 10.1.1.2
GE1/3/1 up 0 30 1 172.168.0.2 (local)
GE1/3/2 up 1 30 1 20.1.1.2
10.1.1.2 GE1/3/0 02:50:49 00:01:31 1 N
20.1.1.2 GE1/3/2 02:49:39 00:01:42 1 N
addresses of PIM entries and information about the upstream interface and downstream interface
list. For example:
(172.168.0.12, 227.0.0.1)
RP: 2.2.2.2
UpTime: 02:54:43
Run the display pim control-message counters command, and you can view statistics about
the received, sent, invalid, and filtered PIM messages. For example:
<HUAWEI> display pim control-message counters interface gigabitethernet1/0/0
PIM global control-message counters:
MessageType Received Sent Invalid Filtered
Register 0 0 0 0
Register-Stop 0 0 0 0
Probe 0 0 0 0
C-RP 0 0 0 0
PIM control-message counters for interface: GigabitEthernet1/0/0

MessageType Received Sent Invalid Filtered
Assert 0 0 0 0
Graft 0 0 0 0
Graft-Ack 0 0 0 0
Hello 6295 3153 3147 0

Join-Prune 3686 0 0 0
State-Refresh 0 0 0 0
BSR 0 0 0 0
3.8 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.
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 adjusting other PIM parameters, complete the following tasks:
l Configuring PIM-SM
l Enabling BFD Globally
3.8.1 Enabling 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 routers that set up the neighbor relationship:

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim bfd enable
PIM BFD is enabled.
By default, PIM BFD is disabled.
----End
3.8.2 (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 routers that set up the neighbor relationship:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The interface view is displayed
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.
By default, the min-tx-interval value is 100 ms, the min-rx-interval value is 100 ms, and the
detect-multiplier value is 3.
When the BFD parameters configured for other protocols are the same as those configured for
PIM, the configurations of the PIM BFD parameters are affected.
----End


After PIM BFD is configured, you can run the command to check information about PIM BFD
sessions.
Procedure
l Run the following commands to check information about a PIM BFD session.
display pim [ vpn-instance vpn-instance-name | all-instance ] bfd session statistics
display pim [ vpn-instance vpn-instance-name | all-instance ] bfd session
[ interface interface-type interface-number | neighbor neighbor-address ] *
----End
Example
Run the display pim all-instance bfd session command, and you can view the information about
PIM BFD sessions. For example:
<HUAWEI> display pim all-instance bfd session
All-instance: Total 4 BFD sessions Created
Total 4 BFD sessions Created
Ethernet6/2/2 (10.1.2.2): Total 2 BFD sessions Created
Neighbor ActTx(ms) ActRx(ms) ActMulti Local/Remote State
10.1.2.3 20 20 5 8756/8652 Up
10.1.2.4 30 30 3 8754/8423 Up
Ethernet2/0/0 (10.20.1.20): Total 2 BFD sessions Created
Neighbor ActTx(ms) ActRx(ms) ActMulti Local/Remote State
10.20.1.30 30 30 5 8327/8891 Up
10.20.1.40 50 50 3 8358/8942 Up
3.9 Maintaining PIM

Maintaining PIM involves resetting PIM statistics, monitoring PIM running status, and
debugging PIM.
3.9.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
Statistics of PIM control messages on an interface cannot be restored after you clear them. So,
confirm the action before you use the command.

Procedure
Step 1 After confirming that you need to clear statistics about PIM control messages, run the reset
pim [ vpn-instance vpn-instance-name | all-instance ] control-message counters [ interface
interface-type interface-number ] command in the user view.
----End
3.9.2 Monitoring the Running Status of PIM

You can monitor the PIM running by checking unicast routes, the BSR, and the RP used by PIM,
statistics about PIM control messages, and information about PIM neighbors and the PIM routing
table.
Context
In routine maintenance, you can run the following commands in any view to view the running
of PIM.
Procedure
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] claimed-route
[ source-address ] command in any view to check information about the unicast routes used
by PIM.
in any view to check information about the BSR in the PIM-SM domain.
l Run the display pim [ vpn-instance vpn-instance-name | all-instance ] control-
message counters [ interface interface-type interface-number | message-type message-
type ] * command in any view to check statistics about PIM control messages.
[ interface-type interface-number ] [ verbose ] command in any view to check information
about the PIM interface.
[ neighbor-address | interface interface-type interface-number ] [ verbose ] command in
any view to check information about the PIM neighbor.
l Run the display pim routing-table command in any view to check information about the
PIM routing table.
display pim [ vpn-instance vpn-instance-name | all-instance ] routing-table [ group-
address [ mask { group-mask-length | group-mask } ] ] [ source-address [ mask
{ source-mask-length | source-mask } ] ] [ outgoing-interface include { interface-
type interface-number | register | none } ] [ fsm ]
display pim routing-table [ group group-address [ mask { group-mask-length | group-
mask } ] ] source source-address [ mask { source-mask-length | source-mask } |
outgoing-interface include { interface-type interface-number | register } ] [ fsm ]
address ] command in any view to check information about the RP serving the multicast
group.
----End


Configuration examples are provided to tell you how to construct a basic PIM network and
configure basic functions of PIM.
3.10.1 Example for Configuring PIM-SM Intra-domain Multicast

In an AS with reachable unicast routes, you can enable basic functions of PIM-SM so that hosts
can receive multicast data from any multicast source.
CAUTION
For the NE5000E, the interface is numbered as slot number/card number/interface number. For
the NE5000E cluster, the interface is numbered as chassis ID/slot number/card number/interface
number. The slot number is chassis ID/slot ID.
It is required to deploy multicast services on the ISP network shown in Figure 3-4. The integrated
Interior Gateway Protocol (IGP) has been deployed on the network. The unicast routes work
normally so that routers can access the Internet. In such a scenario, hosts on the network require
to receive the Video On Demand (VOD) information through multicast services.
Figure 3-4 Networking diagram for configuring PIM-SM intra-domain multicast
RouterA Ethernet
N1
POS3/0/0
GE2/0/0
Ethernet
Receiver
POS1/0/0 HostA
POS2/0/0 PIM-SM
Source RouterE POS3/0/0 Leaf networks
GE3/0/0 POS1/0/0
POS4/0/0 POS2/0/0 GE2/0/0
RouterD POS1/0/0
RouterB HostB
RouterC POS2/0/0
N2
GE1/0/0 Ethernet

POS 3/0/0 192.168.1.1/24 POS 2/0/0 192.168.1.2/24
GE 2/0/0 10.110.1.1/24 POS 4/0/0 10.110.4.1/24
Router B POS 1/0/0 192.168.2.1/24 GE 3/0/0 10.110.5.1/24
GE 2/0/0 10.110.2.1/24 Router E POS 1/0/0 192.168.3.2/24
Router C POS 2/0/0 192.168.3.1/24 POS 2/0/0 192.168.2.2/24

GE 1/0/0 10.110.2.2/24 POS 3/0/0 192.168.9.2/24

POS 4/0/0 192.168.4.1/24
Configuration Notes
When configuring PIM-SM intra-domain multicast, pay attention to the following points:
l PIM-SM and IGMP need to be enabled in sequence on the interfaces connecting the
routers to hosts. That is, enable PIM-SM first and then IGMP.
l If the static RP need be used, you need to configure a same static RP on all the routers.
l If hosts want to receive multicast data from specific sources, enable PIM-SSM. You must
ensure that the SSM group address ranges set on all the routers are the same.
The ISP network access the Internet. To simplify service expansion, you can configure PIM-SM
to provide multicast services on the network.
1. Configure an IP address for each interface on the routers and configure a unicast routing
protocol.
2. Enable multicast routing on all the multicast routers.
4. Enable IGMP on the interface that directly connects the router to hosts.
5. Configure an RP. On a PIM-SM network, the RP is a root node of an RPT. It is
recommended to configure the RP on the router with more multicast flow branches. As
shown in Figure 3-4, Router E is configured as an RP.
6. (Optional) Configure BSR boundaries on the interfaces connected to the Internet. Bootstrap
messages cannot pass through the BSR boundaries and each BSR serves only the local
PIM-SM domain. In this manner, multicast services can be controlled effectively.
7. (Optional) Set the same SSM group address range on all the routers. In this manner, the
multicast router in the PIM-SM domain provides services only for the multicast groups in
the SSM group address range.
Data Preparation
To complete the configuration, you need the following data:
l Multicast group address
l Multicast source address
Procedure
Step 1 Configure an IP address for each interface on the routers and configure a unicast routing protocol.
The detailed configuration procedures are not mentioned here.
Step 2 Enable the multicast function on all the routers and enable PIM-SM on each interface.
# Take Router E as an example. Configurations on Router A, Router B, Router C, and Router
D are similar to those on Router E and hence are not mentioned here.

[~RouterE] multicast routing-enable

[~RouterE] interface pos 1/0/0
[~RouterE-Pos1/0/0] pim sm
[~RouterE-Pos1/0/0] quit
[~RouterE-Pos4/0/0] commit
Step 3 Enable IGMP on the interfaces connected with hosts.
# Take Router A as an example. Configurations on Router B and Router C are similar to those
on Router A and hence are not mentioned here.
[~RouterA-GigabitEthernet2/0/0] igmp version 3

NOTE
You can configure both the static RP and BSR RP or either of them. If both the static RP and BSR RP are
configured, the BSR RP is preferred. You can configure the static RP to be used preferentially by specifying
the keyword preferred in the static-rp rp-address command.
The following shows how to configure both the static RP and BSR RP, with the BSR RP being preferred
and the static RP being the backup.
# Configure a BSR RP. You need to perform the following configurations on one or several
routers in the PIM-SM domain. Here, take Router E as an example to show how to set the service
range of the RP and how to configure the C-BSR and the C-RP.
[~RouterE] acl number 2000
[~RouterE-acl4-basic-2000] rule permit source 225.1.1.0 0.0.0.255
[~RouterE-acl4-basic-2000] quit
[~RouterE] pim
[~RouterE-pim] c-bsr pos 2/0/0
[~RouterE-pim] c-rp pos 2/0/0 group-policy 2000 priority 0
[~RouterE-pim] commit
[~RouterE-pim] quit
# Configure a static RP. You can perform the following configurations on all multicast routers.
Take Router E as an example. Configurations on Router A, Router B, Router C, and Router D
are similar to those on Router E and hence are not mentioned here.
[~RouterE] pim
[~RouterE-pim] static-rp 192.168.4.1
[~RouterE-pim] quit
Step 5 (Optional) Configure a BSR boundary on the interface connecting Router D to the Internet.
[~RouterD-Pos4/0/0] pim bsr-boundary
Step 6 (Optional) Set the SSM group address range.

# Set the SSM group address range to 232.1.1.0/24 on all the routers. Take Router E as an
example. Configurations on Router A, Router B, Router C, and Router D are the same as those
on Router E and hence are not mentioned here.
[~RouterE] pim
[~RouterE-pim] ssm-policy 2001
[~RouterE-pim] quit

# Run the display pim interface command to view information about the PIM interfaces on the
routers. For example, information about the PIM interface on Router E is as follows:
<RouterE> display pim interface
Pos1/0/0 up 1 30 1 192.168.3.2
Pos3/0/0 up 1 30 1 192.168.9.2
Pos4/0/0 up 1 30 1 192.168.4.2
Pos2/0/0 up 1 30 1 192.168.2.2
# Run the display pim bsr-info command to view information about the BSRs on the routers.
For example, information about the BSRs on Router D and Router E is as follows. Information
about the C-BSR on Router E is also displayed.
<RouterD> display pim bsr-info
Priority: 0
Scope: Not scoped
Uptime: 02:08:57
Expires: 00:01:15
C-RP Count: 1
<RouterE> display pim bsr-info
Priority: 0
State: Elected
Scope: Not scoped
Uptime: 02:25:03
C-RP Count: 1
Priority: 0
State: Elected
Scope: Not scoped
Wait to be BSR: 0
# Run the display pim rp-info command to view information about the RPs on the routers. For
example, information about the RPs on Router D andRouter E is as follows:
<RouterD> display pim rp-info
RP: 192.168.2.2
Priority: 0

Uptime: 02:27:17
Expires: 00:02:15
PIM SM static RP information:
Static RP: 192.168.4.1
<RouterE> display pim rp-info
RP: 192.168.2.2 (local)
Priority: 0
Uptime: 02:27:27
Expires: 00:02:03
Static RP: 192.168.4.1 (local)
# Run the display pim routing-table command to view information about the PIM routing tables
on the routers. Host A needs to receive the data for multicast group 225.1.1.1/24 and host B
needs to receive the data sent from source 10.110.5.100/24 to group 232.1.1.1/24. For example,
information about the PIM routing tables on Router D andRouter E is as follows:

(10.110.5.100, 225.1.1.1)
RP: 192.168.2.2
UpTime: 00:57:20
1: Pos2/0/0
(10.110.5.100, 232.1.1.1)
UpTime: 00:31:21
1: Pos1/0/0
<RouterE> display pim routing-table

(*, 225.1.1.1)
RP: 192.168.2.2 (local)
UpTime: 00:21:40
Upstream interface: register
1: Pos3/0/0
(10.110.5.100, 232.1.1.1)
Protocol: pim-ssm, Flag:
UpTime: 00:18:44


1: Pos1/0/0
----End
Configuration Files
#
sysname RouterA
#
#
acl number 2001
rule 5 permit source 232.1.1.0 0.0.0.255
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp version 3
isis enable 1
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.9.1 255.255.255.0
pim sm
isis enable 1
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
pim sm
isis enable 1
#
pim
ssm-policy 2001
static-rp 192.168.4.1
#
return

#
sysname RouterB
#
#
acl number 2001
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
igmp version 3

isis enable 1
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.2.1 255.255.255.0
pim sm
isis enable 1
#
pim
ssm-policy 2001
static-rp 192.168.4.1
#
return
#
sysname RouterC
#
#
acl number 2001
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
igmp version 3
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.3.1 255.255.255.0
pim sm
isis enable 1
#
pim
ssm-policy 2001
static-rp 192.168.4.1
#
return
#
sysname RouterD
#
#
acl number 2001
#
isis 1
network-entity 10.0000.0000.0004.00
#
undo shutdown
pim sm
isis enable 1
ip address 10.110.5.1 255.255.255.0
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.4.2 255.255.255.0

pim sm
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.1.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos4/0/0
undo shutdown
link-protocol ppp
ip address 10.110.4.1 255.255.255.0
pim bsr-boundary
pim sm
isis enable 1
#
pim
ssm-policy 2001
static-rp 192.168.4.1
#
return
l Configuration file of Router E
#
sysname RouterE
#
#
acl number 2000
#
acl number 2001
#
isis 1
network-entity 10.0000.0000.0005.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.3.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.2.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 192.168.9.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos4/0/0
link-protocol ppp
ip address 192.168.4.1 255.255.255.0
pim sm
isis enable 1
#
pim
ssm-policy 2001
static-rp 192.168.4.1
c-bsr Pos2/0/0

c-rp Pos2/0/0 group-policy 2000

#
return
3.10.2 Example for Configuring a PIM-SM BSR Administrative

Domain
On a PIM-SM network where a dynamic RP is used, configuring a BSR administrative domain
enables C-BSRs to serve groups in a specified group address range.
CAUTION
As shown in Figure 3-5, multicast services are deployed on the ISP network. An IGP has been
deployed to ensure that unicast routes are available. The ISP network is connected to the Internet.
The router must be properly configured so that the hosts on the network can receive VOD
information in multicast mode.
Figure 3-5 Networking diagram for configuring a PIM-SM BSR administrative domain
RouterA Ethernet
N1
POS3/0/0
GE2/0/0
Ethernet
Receiver
POS1/0/0 HostA
POS2/0/0 PIM-SM
GE3/0/0 POS1/0/0
POS4/0/0 POS2/0/0 GE2/0/0
RouterD POS1/0/0
RouterB HostB
RouterC POS2/0/0
N2
GE1/0/0 Ethernet
Device Interface IP Address

Router A POS 1/0/0 192.168.9.1/24
POS 3/0/0 192.168.1.1/24
GE 2/0/0 10.110.1.1/24
Router B POS 1/0/0 192.168.2.1/24
GE 2/0/0 10.110.2.1/24
Router C POS 2/0/0 192.168.3.1/24
GE 1/0/0 10.110.2.2/24
Router D POS 1/0/0 192.168.4.2/24
POS 2/0/0 192.168.1.2/24

POS 4/0/0 10.110.4.1/24

GE 3/0/0 10.110.5.1/24
Router E POS 1/0/0 192.168.3.2/24
POS 2/0/0 192.168.2.2/24
POS 3/0/0 192.168.9.2/24
POS 4/0/0 192.168.4.1/24
Precautions
When configuring a PIM-SM BSR administrative domain, note the following points:
l Unicast routes on the network must be reachable because multicast routing depends on
unicast routing.
l Multicast routing needs to be enabled on all routers.
l PIM-SM needs to be enabled on the interfaces connecting routers, the interface directly
connecting the router to the multicast source, and the interface directly connecting the
router to hosts.
l If a static RP is used, the static RP configurations on all the routers must be the same.
l IGMP of a supported version needs to be run on the router directly connected to hosts. PIM-
SM and IGMP need to be enabled in sequence (that is, first PIM-SM and then IGMP) on
the interface directly connected to hosts; otherwise, the PIM-SM function fails to be
configured.
l If users need to receive data sent by a specified multicast source, PIM-SSM needs to be
enabled and the same SSM group address range needs to be configured on all the routers.
protocol.
2. Enable multicast routing on all routers providing multicast services.
5. Configure RPs. An RP is the root node of an RPT on a PIM-SM network. Setting an RP
on the router that has more branches, for example, Router E in Figure 3-5, is recommended.
6. (Optional) Set a BSR boundary on the interface connected to the Internet. Bootstrap
messages cannot pass through the BSR boundary. Therefore, the BSR serves only a
specified PIM-SM domain. This increases multicast controllability.
7. (Optional) Configure the same SSM group address range on each router. This enables the
multicast routers in the PIM-SM domain to provide services only for multicast groups in
the SSM group address range.
Data Preparation

l Multicast group address (225.1.1.1/24)

l Multicast source address (10.110.5.100/24)
l SSM group address range (232.1.1.0/24)
Procedure
Step 2 Enable multicast on each device and PIM-SM on each interface of the devices.
# Enable multicast on each router and PIM-SM on each interface of the routers. The
configurations of Router B, Router C, Router D, and Router E are similar to those on Router A,
and are not provided here.
[~RouterA] multicast routing-enable
[~RouterA-GigabitEthernet2/0/0] pim sm
[~RouterA] interface pos 1/0/0
[~RouterA-Pos1/0/0] pim sm
[~RouterA-Pos1/0/0] quit
[~RouterA-Pos3/0/0] commit
Step 3 Enable IGMP on the interface directly connected to hosts. The configuration details are not
provided here.
Step 4 Configure RPs.
NOTE
You can choose to configure both a static RP and a dynamic RP, or only one of them. When both a static
RP and a dynamic RP are configured, the dynamic RP is preferred. You can enable the static RP to be
preferred by setting the keyword preferred in the static-rp rp-address command.
In this example, a static RP and a dynamic RP are configured. The dynamic RP is preferred, and the static
RP functions as the backup of the dynamic RP.
# Configure a dynamic RP. Perform the following configurations on one or more routers in the
PIM-SM domain. On Router E, set the range of groups severed by the RP and locations of C-
BSRs and C-RPs.
[~RouterE-acl-basic-2005] rule permit source 225.1.1.0 0.0.0.255
[~RouterE-acl-basic-2005] quit
[~RouterE] pim
[~RouterE-pim] quit
# Configure a static RP on all multicast routers. In this example, perform the following
configurations on Router A, Router B, Router C, Router D, and Router E. The configurations
of Router B, Router C, Router D, and Router E are similar to those on Router A, and are not
provided here.
[~RouterA] pim
[~RouterA-pim] static-rp 192.168.2.2
[~RouterA-pim] quit
Step 5 (Optional) Configure a BSR boundary on the interface that connects Router D to the Internet.


Step 6 (Optional) Set an SSM group address range.

# Set the SSM group address range to 232.1.1.0/24 on all routers. The configurations of
Router B, Router C, Router D, and Router E are similar to those on Router A, and are not provided
here.
[~RouterA-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[~RouterA-acl-basic-2000] quit
[~RouterA] pim
[~RouterA-pim] quit

# Run the display pim interface command to check information about PIM interfaces on each
router. For example, the information about PIM interfaces on Router C is displayed as follows:
<RouterC> display pim interface
GE1/0/0 up 0 30 1 10.110.2.2 (local)
Pos2/0/0 up 1 30 1 192.168.3.1
# Run the display pim bsr-info command to check BSR information on each router. For
example, the BSR information on Router A and Router E is displayed as follows (C-BSR
information is also displayed on Router E):
<RouterA> display pim bsr-info
Priority: 0
Scope: Not scoped
Uptime: 01:40:40
Expires: 00:01:42
C-RP Count: 1
Priority: 0
State: Elected
Scope: Not scoped
Uptime: 00:00:18
Next BSR message scheduled at :00:01:42
C-RP Count: 1
Candidate BSR Address is: 192.168.9.2
Priority: 0
State:Elected
Scope: Not scoped
Wait to be BSR: 0
# Run the display pim rp-info command to check RP information on each router. For example,
the RP information on Router A is displayed as follows:
<RouterA> display pim rp-info


RP: 192.168.9.2
Priority: 0
Uptime: 00:45:13
Expires: 00:02:17
Static RP: 192.168.2.2
# Run the display pim routing-table command to check the PIM routing table on each router.
Host A wants to receive data for multicast group 225.1.1.1/24, and Host B wants to receive data
sent by multicast source 10.110.5.100/24 to multicast group 232.1.1.1/24. The command output
is as follows:
(*, 225.1.1.1)
RP: 192.168.9.2
UpTime: 00:13:46
Upstream interface: Pos1/0/0,
RPF neighbor: 192.168.9.2
1: GigabitEthernet2/0/0,
Protocol: igmp, UpTime: 00:13:46, Expires:-
(10.110.5.100, 225.1.1.1)
RP: 192.168.9.2
UpTime: 00:00:42
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
1: Pos2/0/0
(10.110.5.100, 232.1.1.1)
UpTime: 00:01:20
1: Pos1/0/0
Protocol: pim-ssm, UpTime: 00:01:20, Expires:-
(*, 225.1.1.1)
RP: 192.168.9.2 (local)


UpTime: 00:13:16
Upstream interface: Register
1: Pos3/0/0
(10.110.5.100, 232.1.1.1)
UpTime: 00:01:22
1: Pos1/0/0
<RouterC> display pim routing-table
Total 1 (S, G) entry
(10.110.5.100, 232.1.1.1)
UpTime: 00:01:25
----End
Configuration Files
#
sysname RouterA
#
#
acl number 2000
#
undo shutdown
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp version 3
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.9.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
ssm-policy 2000
static-rp 192.168.2.2
#
return
#
sysname RouterB
#
#
acl number 2000
#
undo shutdown
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
igmp version 3
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
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
ssm-policy 2000
static-rp 192.168.2.2
#
return
#
sysname RouterC
#
#
acl number 2000
#
undo shutdown
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
igmp version 3
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
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

ssm-policy 2000
static-rp 192.168.2.2
#
return
#
sysname RouterD
#
#
acl number 2000
#
undo shutdown
ip address 10.110.5.1 255.255.255.0
pim sm
#
interface Pos4/0/0
undo shutdown
link-protocol ppp
ip address 10.110.4.1 255.255.255.0
pim sm
pim bsr-boundary
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
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
ssm-policy 2000
static-rp 192.168.2.2
#
return
#
sysname RouterE
#
#
acl number 2000
#
acl number 2005
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface Pos2/0/0

undo shutdown
link-protocol ppp
ip address 192.168.2.2 255.255.255.0
pim sm
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 192.168.9.2 255.255.255.0
pim sm
#
interface Pos4/0/0
undo shutdown
link-protocol ppp
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
ssm-policy 2000
static-rp 192.168.2.2
c-bsr Pos3/0/0
c-rp Pos3/0/0 group-policy 2005 priority 0
#
return
3.10.3 Example for Configuring PIM-SM Security

To prevent malicious packet attacks, you can configure various filtering policies, for example,
setting a valid source address range or a valid C-RP address range, to improve the security of
the PIM network.
CAUTION
IGP is deployed on the network to implement normal unicast routing. In such a scenario, you
can configure filtering policies on the routers to improve the security of the multicast network
so that hosts can receive secure and reliable multicast data.

Figure 3-6 example for configuring PIM-SM security
RouterA Ethernet
N1
POS3/0/0
GE2/0/0
Ethernet
Receiver
POS1/0/0 HostA
POS2/0/0 PIM-SM
GE3/0/0 POS1/0/0
POS4/0/0 POS2/0/0 GE2/0/0
POS1/0/0 Receiver
RouterD POS1/0/0
RouterB HostB
RouterC POS2/0/0
N2
GE1/0/0 Ethernet

RouterA POS 1/0/0 192.168.9.1/24 RouterD POS 1/0/0 192.168.4.2/24
POS 3/0/0 192.168.1.1/24 POS 2/0/0 192.168.1.2/24
GE 2/0/0 10.110.1.1/24 GE 3/0/0 10.110.5.1/24
RouterB POS 1/0/0 192.168.2.1/24 RouterE POS 1/0/0 192.168.3.2/24
GE 2/0/0 10.110.2.1/24 POS 2/0/0 192.168.2.2/24
RouterC POS 2/0/0 192.168.3.1/24 POS 3/0/0 192.168.9.2/24
GE 1/0/0 10.110.2.2/24 POS 4/0/0 192.168.4.1/24
Configuration Notes
When configuring PIM security, pay attention to the following points:
l The range of multicast groups that each C-RP serves and the valid C-RP address range can
be set only on the C-BSR.
l Source address-based and BSR address-based filtering policies need be configured on all
the routers.
l Policies for filtering Register messages need be configured on all C-RPs.
l Policies for filtering Join/Prune messages are commonly configured on the last-hop
routers.
Configure PIM-SM to implement the multicast functions on the network. The filtering policies
of ensuring PIM network security include setting the valid ranges of the source address, BSR
address, and RP address, and filtering Register messages, Join/Prune message, and PIM
neighbors.
protocol.


4. Enable IGMP on the routers connected to hosts.
5. Configure C-BSRs and C-RPs if the BSR RP needs to be used.
6. Set the range of multicast groups that each C-RP serves on the C-BSR.
7. Create a policy for filtering Register messages on the C-RP to avoid the attacks of the
Register messages carrying illegal multicast source information.
8. Create source address-based filtering policies on all the routers to deny all the multicast
packets from illegal sources.
9. Create BSR address-based filtering policies on all the routers to avoid BSR spoofing.
Data Preparation
l IP address of the multicast source
l ACL rules for defining various filtering policies
Procedure
# Take Router A as an example. Configurations on Router B, Router C, Router D, and Router
E are similar to those on Router A and hence are not mentioned here.

[~RouterA-GigabitEthernet2/0/0] igmp version 3
Step 4 Configure C-BSRs and C-RPs.

# Configure a C-BSR and a C-RP on Router E.
[~RouterE] pim
[~RouterE-pim] c-rp pos 2/0/0
[~RouterE-pim] quit

Step 5 Set the range of multicast groups that each C-RP serves and the valid C-RP address range on
the C-BSR.
# Set the range of multicast groups that each C-RP serves and the valid C-RP address range on
Router E.
[~RouterE-acl4-advance-3000] rule permit ip source 192.168.2.2 0 destination
225.1.1.0 0.0.0.255
[~RouterE-acl4-advance-3000] quit
[~RouterE] pim
[~RouterE-pim] crp-policy 3000
[~RouterE-pim] quit
Step 6 Create a policy for filtering Register messages on the C-RP.

# Create a policy for filtering Register messages on Router E.
[~RouterE-acl4-advance-3001] rule permit ip source 10.110.5.0 0.0.0.255
destination 225.1.1.0 0.0.0.255
[~RouterE-acl4-advance-3001] quit
[~RouterE] pim
[~RouterE-pim] register-policy 3001
[~RouterE-pim] quit
Step 7 Create source address-based and BSR address-based filtering policies on all the routers.
# Take Router E as an example. Configurations on Router A, Router B, Router C, and Router
D are similar to those on Router E and hence are not mentioned here.
[~RouterE] pim
[~RouterE-pim] source-policy 2000
[~RouterE-pim] bsr-policy 2001
[~RouterE-pim] quit

# Run the display pim bsr-info command to view information about the BSR on the router. The
BSR address matches the filtering rule. For example, information about the BSRs on Router D
andRouter E is as follows:
<RouterD> display pim bsr-info
Priority: 0
Scope: Not scoped
Uptime: 21:56:56
Expires: 00:02:01
C-RP Count: 1
Priority: 0

State: Elected
Scope: Not scoped
Uptime: 21:57:15
C-RP Count: 1
Priority: 0
State: Elected
Scope: Not scoped
Wait to be BSR: 0
# Run the display pim rp-info command to view information about the RPs on the routers. The
RP address matches the filtering rule. For example, information about the RPs on Router D
andRouter E is as follows:
<RouterD> display pim rp-info
PIM-SM BSR RP infomation:
RP: 192.168.2.2
Priority: 0
Uptime: 01:27:21
Expires: 00:02:11
<RouterE> display pim rp-info
PIM-SM BSR RP infomation:
RP: 192.168.2.2 (local)
Priority: 0
Uptime: 01:29:10
Expires: 00:02:20
# Run the display pim routing-table command to view information about the PIM routing tables
on the routers. Hosts can receive multicast data from a valid multicast source. Multicast source
10.110.5.100 sends multicast data and Host A needs to receive the data for multicast group
225.1.1.1/24 and host B needs to receive the data for group 225.1.1.2/24. For example,
information about the PIM routing tables on Router D andRouter E is as follows:

(10.110.5.100, 225.1.1.1)
RP: 192.168.2.2
UpTime: 00:57:20
1: Pos2/0/0
(10.110.5.100, 225.1.1.2)
RP: 192.168.2.2
UpTime: 01:56:45
1: Pos1/0/0


Total 2 (*, G) entries; 1 (S, G) entry
(*, 225.1.1.1)
RP: 192.168.2.2 (local)
UpTime: 00:21:40
1: Pos3/0/0
(*, 225.1.1.2)
RP: 192.168.2.2 (local)
UpTime: 00:21:40
1: Pos1/0/0
(10.110.5.100, 225.1.1.2)
RP: 192.168.2.2
UpTime: 01:56:45
1: Pos1/0/0
----End
Configuration Files
#
sysname RouterA
#
#
acl number 2000
#
acl number 2001
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp version 3
isis enable 1
#

interface Pos1/0/0
undo shutdown
ip address 192.168.9.1 255.255.255.0
pim sm
isis enable 1
#
interface Pos3/0/0
undo shutdown
ip address 192.168.1.1 255.255.255.0
isis enable 1
pim sm
#
pim
bsr-policy 2001
source-policy 2000
#
return
#
sysname RouterB
#
#
acl number 2000
#
acl number 2001
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.110.2.1 255.255.255.0
isis enable 1
pim sm
igmp enable
igmp version 3
#
interface Pos1/0/0
ip address 192.168.2.1 255.255.255.0
isis enable 1
pim sm
#
pim
bsr-policy 2001
source-policy 2000
#
return
#
sysname RouterC
#
#
acl number 2000
#
acl number 2001
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.110.2.2 255.255.255.0

isis enable 1
pim sm
igmp enable
igmp version 3
#
interface Pos2/0/0
ip address 192.168.3.1 255.255.255.0
pim sm
isis enable 1
#
pim
bsr-policy 2001
source-policy 2000
#
return
#
sysname RouterD
#
#
acl number 2000
#
acl number 2001
#
isis 1
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.110.5.1 255.255.255.0
pim sm
isis enable 1
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.4.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.1.2 255.255.255.0
pim sm
isis enable 1
#
pim
bsr-policy 2001
source-policy 2000
#
return
#
sysname RouterE
#
#
acl number 2000
#
acl number 2001
#
acl number 3000

rule 5 permit ip source 192.168.2.2 0 destination 225.1.1.0 0.0.0.255

#
acl number 3001
rule 5 permit ip source 10.110.5.0 0.0.0.255 destination 225.1.1.0 0.0.0.255
#
isis 1
network-entity 10.0000.0000.0005.00
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.3.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.2.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 192.168.9.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos4/0/0
undo shutdown
link-protocol ppp
ip address 192.168.4.1 255.255.255.0
pim sm
isis enable 1
#
pim
bsr-policy 2001
register-policy 3001
source-policy 2000
c-bsr Pos2/0/0
crp-policy 3000
c-rp Pos2/0/0
#
return
3.10.4 Example for Configuring SPT Switchover in a PIM-SM

Domain
An RP performs an SPT switchover after receiving the Register message and a receiver's DR
performs an SPT switchover after receiving the first multicast data packet. To perform an SPT
switchover only after the rate of multicast data packets reaches the upper threshold, configure
the conditions for triggering an SPT switchover.
CAUTION

deployed to ensure that unicast routes are available. The ISP network is connected to the Internet.
The router must be properly configured so that the hosts on the network can receive VOD
information in multicast mode.
Figure 3-7 Networking diagram for configuring SPT switchover in a PIM-SM domain
RouterA Ethernet
N1
POS3/0/0
GE2/0/0
Ethernet
Receiver
POS1/0/0 HostA
POS2/0/0 PIM-SM
GE3/0/0 POS1/0/0
POS4/0/0 POS2/0/0 GE2/0/0
RouterD POS1/0/0
RouterB HostB
RouterC POS2/0/0
N2
GE1/0/0 Ethernet
Device Interface IP Address

Router A POS 1/0/0 192.168.9.1/24
POS 3/0/0 192.168.1.1/24
GE 2/0/0 10.110.1.1/24
Router B POS 1/0/0 192.168.2.1/24
GE 2/0/0 10.110.2.1/24
Router C POS 2/0/0 192.168.3.1/24
GE 1/0/0 10.110.2.2/24
Router D POS 1/0/0 192.168.4.2/24
POS 2/0/0 192.168.1.2/24
POS 4/0/0 10.110.4.1/24
GE 3/0/0 10.110.5.1/24
Router E POS 1/0/0 192.168.3.2/24
POS 2/0/0 192.168.2.2/24
POS 3/0/0 192.168.9.2/24
POS 4/0/0 192.168.4.1/24
Precautions
When configuring the SPT switchover in a PIM-SM domain, note the following points:
l Unicast routes on the network must be reachable because multicast routing is based on
unicast routing.
l Multicast routing needs to be enabled on all routers.
l PIM-SM needs to be on the interfaces connecting routers, interface directly connecting the
router to the multicast source, and interface directly connecting the router to hosts.

l IGMP of a supported version needs to be run on the router directly connected to hosts. PIM-
SM and IGMP need to be enabled in sequence (that is, first PIM-SM and then IGMP) on
the interface directly connected to hosts; otherwise, the PIM-SM function fails to be
configured.
l When users need to receive data sent by a specified multicast source, PIM-SSM needs to
be enabled and the same SSM group address range needs to be configured on all the
routers.
protocol.
2. Enable multicast routing on all routers providing multicast services.
3. Enable PIM-SM on all interfaces of multicast routers.
5. Configure RPs. An RP is the root node of an RPT in a PIM-SM network. Setting an RP on
the router that has more branches, for example, Router E in Figure 3-7, is recommended.
messages cannot pass through the BSR boundary. Therefore, the BSR serves only this PIM-
SM domain. This increases multicast controllability.
7. (Optional) Configure the SSM group address range on each router. This enables the
multicast routers in the PIM-SM domain to provide services only for multicast groups with
addresses being in the SSM group address range.
Data Preparation
l Multicast group address (225.1.1.1/24)
l Multicast source address (10.110.5.100/24)
l SSM group address range (232.1.1.0/24)
Procedure
Step 2 Enable multicast on each device and PIM-SM on each interface of the devices.
# Enable multicast on each router and PIM-SSM on each interface of the Routers. The
configurations of Router B, Router C, Router D, and Router E are similar to those on Router A,
and are not provided here.


Step 3 Enable IGMP on the interface directly connected to hosts. The configuration details are not
provided here.

NOTE
preferred by setting preferred in the static-rp rp-address command.
In this example, a static RP and a dynamic RP are configured. The dynamic RP is preferred, and the static
RP functions as the backup of the dynamic RP.
PIM-SM domain. On Router E, set the range of groups severed by the RP and locations of C-
BSRs and C-RPs.
[~RouterE-acl-basic-2005] rule permit source 225.1.1.0 0.0.0.255
[~RouterE-acl-basic-2005] quit
[~RouterE] pim
# Configure a static RP on all multicast routers. In this example, perform the following
configurations on Router A, Router B, Router C, Router D, and Router E. The configurations
of Router B, Router C, Router D, and Router E are similar to those on Router A, and are not
provided here.
[~RouterA] pim
[~RouterA-pim] static-rp 192.168.2.2
Step 5 (Optional) Configure a BSR boundary on the interface that connects Router D to the Internet.
Step 6 (Optional) Set an SSM group address range.
# Set the SSM group address range to 232.1.1.0/24 on all routers. The configurations of
Router B, Router C, Router D, and Router E are similar to those on Router A, and are not provided
here.
[~RouterA-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[~RouterA-acl-basic-2000] quit
[~RouterA] pim
# Run the display pim interface command to check PIM interfaces on each router. For example,
the information about PIM interfaces on Router C is displayed as follows:
<RouterC> display pim interface
GE1/0/0 up 0 30 1 10.110.2.2 (local)
Pos2/0/0 up 1 30 1 192.168.3.1

# Run the display pim bsr-info command to check BSR information on each router. For
example, the BSR information on Router A and Router E (C-BSR information is also displayed
on Router E) is displayed as follows:
<RouterA> display pim bsr-info
Priority: 0
Scope: Not scoped
Uptime: 01:40:40
Expires: 00:01:42
C-RP Count: 1
Priority: 0
State: Elected
Scope: Not scoped
Uptime: 00:00:18
Next BSR message scheduled at :00:01:42
C-RP Count: 1
Candidate BSR Address is: 192.168.9.2
Priority: 0
State:Elected
Scope: Not scoped
Wait to be BSR: 0
# Run the display pim rp-info command to check RP information on each router. For example,
the RP information on Router A is displayed as follows:
<RouterA> display pim rp-info
RP: 192.168.9.2
Priority: 0
Uptime: 00:45:13
Expires: 00:02:17
Static RP: 192.168.2.2
# Run the display pim routing-table command to check the PIM routing table on each router.
Host A needs to receive data for multicast group 225.1.1.1/24, and Host B needs to receive data
sent by multicast source 10.110.5.100/24 to multicast group 232.1.1.1/24. The command output
as follows:
(*, 225.1.1.1)
RP: 192.168.9.2
UpTime: 00:13:46
Upstream interface: Pos1/0/0,
(10.110.5.100, 225.1.1.1)

RP: 192.168.9.2
UpTime: 00:00:42
(10.110.5.100, 225.1.1.1)
RP: 192.168.9.2
UpTime: 00:00:42
1: Pos2/0/0
(10.110.5.100, 232.1.1.1)
UpTime: 00:01:20
1: Pos1/0/0
(*, 225.1.1.1)
RP: 192.168.9.2 (local)
UpTime: 00:13:16
1: Pos3/0/0
(10.110.5.100, 232.1.1.1)
UpTime: 00:01:22
1: Pos1/0/0
Total 1 (S, G) entry
(10.110.5.100, 232.1.1.1)
UpTime: 00:01:25

----End
Configuration Files
#
sysname RouterA
#
#
acl number 2000
#
undo shutdown
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp version 3
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.9.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
ssm-policy 2000
static-rp 192.168.2.2
#
return

#
sysname RouterB
#
#
acl number 2000
#
undo shutdown
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
igmp version 3
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
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
ssm-policy 2000
static-rp 192.168.2.2
#
return
#
sysname RouterC
#
#
acl number 2000
#
undo shutdown
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
igmp version 3
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
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
ssm-policy 2000
static-rp 192.168.2.2
#
return
#
sysname RouterD
#
#
acl number 2000
#
undo shutdown
ip address 10.110.5.1 255.255.255.0
pim sm
#
interface Pos4/0/0
undo shutdown
link-protocol ppp
ip address 10.110.4.1 255.255.255.0
pim bsr-boundary
pim sm
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.1.2 255.255.255.0

pim sm
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
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
ssm-policy 2000
static-rp 192.168.2.2
#
return
#
sysname RouterE
#
#
acl number 2000
#
acl number 2005
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.2.2 255.255.255.0
pim sm
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 192.168.9.2 255.255.255.0
pim sm
#
interface Pos4/0/0
undo shutdown
link-protocol ppp
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
ssm-policy 2000
static-rp 192.168.2.2
c-bsr Pos3/0/0
c-rp Pos3/0/0 group-policy 2005 priority 0
#

return
3.10.5 Example for Configuring PIM-SSM Multicast

In an AS with reachable unicast routes, you can configure basic PIM-SSM functions so that
hosts can receive multicast data from a specified multicast source.
CAUTION
IGP is deployed on the network to implement normal unicast routing. Hosts on the network then
need to join source-specific multicast groups.
Figure 3-8 Networking diagram for configuring PIM-SSM multicast
Ethernet PIM-SSM
Leaf networks
RouterA
POS1/0/0 POS2/0/0
Source
GE2/0/0 POS1/0/0 POS1/0/0 GE2/0/0
RouterB RouterC
Receiver
HostA
Ethernet

RouterA POS 1/0/0 192.168.2.1/24 Router C POS 1/0/0 192.168.4.2/24
GE 2/0/0 10.110.1.2/24 GE 2/0/0 10.110.2.1/24
RouterB POS 1/0/0 192.168.2.2/24
POS 2/0/0 192.168.4.1/24
Configuration Notes
When configuring PIM-SSM multicast, pay attention to the following points:

l You must ensure that the SSM group address ranges set on all the routers are the same.
l An RP need not be configured on the PIM-SSM network.
Configure PIM-SSM to implement source-specific multicast on the network.
protocol.
4. Enable IGMP on the routers connected to hosts.
5. Set the same SSM group address range on all the routers.
Data Preparation
l IP address of the multicast source
Procedure
The detailed configuration procedure is not mentioned here.

# Enable IGMP on the interface connecting Router C to the host and set the IGMP version to 3.
[~RouterC] interface gigabitethernet 2/0/0
[~RouterC-GigabitEthernet2/0/0] igmp enable
[~RouterC-GigabitEthernet2/0/0] igmp version 3
[~RouterC-GigabitEthernet2/0/0] commit
[~RouterC-GigabitEthernet2/0/0] quit

# Set the SSM group address range to 232.1.1.0/24 on all the routers. Take Router A as an
example. Configurations on Router B and Router C are the same as those on Router A and hence
are not mentioned here.


[~RouterA-acl4-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[~RouterA] pim
[~RouterA-pim] quit

# Host A needs to receive the data sent from source 10.110.1.1/24 to group 232.1.1.1/24. Run
the display pim routing-table command to view information about the PIM routing tables on
the routers. The display on Router A and Router B is as follows:

(10.110.1.1, 232.1.1.1)
UpTime: 00:02:13
1: Pos1/0/0
<RouterB> display pim routing-table

(10.110.1.1, 232.1.1.1)
UpTime: 00:09:15
1: Pos2/0/0
----End
Configuration Files
#
sysname RouterA
#
#
acl number 2000
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.110.1.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos1/0/0

undo shutdown
link-protocol ppp
ip address 192.168.2.1 255.255.255.0
pim sm
isis enable 1
#
pim
ssm-policy 2000
#
return
#
sysname RouterB
#
#
acl number 2000
#
isis 1
network-entity 10.0000.0000.0002.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.2.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.4.1 255.255.255.0
pim sm
isis enable 1
#
pim
ssm-policy 2000
#
return
#
sysname RouterC
#
#
acl number 2000
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
igmp version 3
isis enable 1
#
interface Pos1/0/0
undo shutdown
ip address 192.168.4.2 255.255.255.0
pim sm
isis enable 1
#
pim
ssm-policy 2000

#
return

Configuration Guide - IP Multicast 4 MSDP Configuration
4 MSDP Configuration
About This Chapter
The MSDP protocol is used to implement multicast routing and data forwarding between PIM-
SM domains and anycast RP in a PIM-SM domain.
4.1 MSDP Overview

MSDP 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.
4.2 MSDP Features Supported by the NE5000E
NE5000E implements PIM-SM inter-domain multicast and anycast RP in a PIM-SM domain
through MSDP. You can control the connections between MSDP peers, adjust SA message
parameters, and configure authentication for MSDP peers and filtering policies of SA messages
to enhance MSDP security. The NE5000E supports multi-instance MSDP.
4.3 Configuring PIM-SM Inter-domain Multicast
When a multicast network is divided into multiple PIM-SM domains, MSDP is required to
connect RPs in different domains and enable RPs to share multicast source information. As a
result, hosts in the local PIM-SM domain can receive the multicast data sent by the multicast
sources in other domains.
4.4 Configuring Anycast RP
Anycast RP indicates that multiple RPs with the same address reside in the same PIM-SM
domain and MSDP peer relationships are set up between these RPs; therefore IP routing
automatically selects the topologically closest RP for each source and receiver. This reduces
burdens on a single RP, implements RP backup, and optimizes the forwarding path.
4.5 Controlling MSDP Peer Connections
MSDP peers communicate through TCP connections. You can flexibly control the sessions set
up between MSDP peers by closing or reestablishing TCP connections. In addition, you can also
adjust the period for retrying to set up MSDP peer connections and configure MSDP peer
authentication to improve the security of TCP connections.
4.6 Adjusting the Parameters of SA Messages
MSDP peers share (S, G) information by exchanging SA messages. You can configure the
capacity of the SA cache, enable the sending of SA Request messages, enable the encapsulation

of multicast data into SA messages, and create filtering policies of SA messages and SA Request
messages.
4.7 Maintaining MSDP
Maintaining MSDP involves clearing MSDP peer statistics and (S, G) information in the SA
cache, monitoring MSDP running status, and debugging MSDP for fault location.
Configuration examples are provided to tell you how to implement the MSDP RPF check through
BGP or static RPF neighbors, how to implement PIM-SM inter-domain multicast, inter-AS
multicast, and how to configure anycast RP in a PIM-SM domain.

4.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.
On a basic PIM-SM network, a multicast source registers with only the Rendezvous Point (RP)
in the local Protocol Independent Multicast Sparse Mode (PIM-SM) domain. Multicast source
information is isolated between domains and therefore an RP knows only the multicast source
in the local domain and sets up a Multicast Distribution Tree (MDT) for multicast data
forwarding to hosts in the domain.
If there is a mechanism that can transfer information about multicast sources of other domains
to the RP in the local domain, the RP in the local domain can send Join messages to the multicast
sources of other PIM-SM domains and set up MDTs between the local domain and remote
domains. Therefore, multicast data packets can be transmitted across domains and the group
members in the local domain can receive multicast data sent by the multicast sources in other
domains.
Multicast Source Discovery Protocol (MSDP) is such a mechanism. MSDP is an inter-domain
multicast solution to the interconnection among multiple PIM-SM domains. MSDP functions
to set up an MSDP peer relationship between RPs in different PIM-SM domains. MSDP peers
exchange (S, G) information by sending Source Active (SA) messages. The SA messages, at
last, are transmitted from the RP with which the local multicast source registers to the RPs to
which group members in other PIM-SM domains join.
MSDP peers set up TCP connections and perform the Reverse Path Forwarding (RPF) check on
the received SA messages.
NOTE
MSDP is applicable only to PIM-SM and useful only for the Any Source Multicast (ASM) model.
MSDP peer relationships can be set up between RPs in the same PIM-SM domain. In this manner,
information about the multicast source is shared by RPs in the domain and thus anycast RP is
implemented.
4.2 MSDP Features Supported by the NE5000E

NE5000E implements PIM-SM inter-domain multicast and anycast RP in a PIM-SM domain
through MSDP. You can control the connections between MSDP peers, adjust SA message
parameters, and configure authentication for MSDP peers and filtering policies of SA messages
to enhance MSDP security. The NE5000E supports multi-instance MSDP.
PIM-SM Inter-domain Multicast

connect RPs in different domains and enable RPs to share multicast source information. At last,
hosts in the local PIM-SM domain can receive the multicast data sent by the multicast sources
in other domains.
You can configure intra-AS MSDP peers, inter-AS MSDP peers, and static RPF peers to connect
RPs in different PIM-SM domains.

Anycast RP in a PIM-SM Domain

Anycast RP in a PIM-SM domain enables a multicast source to register with the topologically
closest RP or a receiver to join the topologically closest RP. This releases burdens on a single
RP, implements RP backup, and optimizes the forwarding path.
You can configure a loopback interface as a Candidate-RP (C-RP) or a static RP and set the
loopback interface address as the logical RP address of SA messages.
Connection Control Between MSDP Peers

The NE5000E supports the start and close of MSDP sessions. In addition, setting the period
within which an RP can retransmit the request for setting up a TCP connection to the remote
MSDP peer is also allowed.
MSDP Peer Authentication

Configuring MSDP MD5 or Key-Chain authentication can improve the security of TCP
connections set up between MSDP peers. 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.
SA Cache
By default, the SA cache function is enabled on the router. The (S, G) information carried in the
SA messages is then cached locally. If the router requires receiving multicast data, it directly
obtains useful (S, G) information from the SA cache. Setting the maximum number of (S, G)
entries in an SA cache can prevent the Deny of Service (DoS) attack.
You are allowed to disable the SA cache function on the router. After the SA cache function is
disabled, the router no longer saves (S, G) information carried in the SA messages locally. If the
router requires receiving multicast data, it should wait for the SA message sent by the MSDP
peer in the next sending period. This may result in a delay in obtaining multicast source
information.
Transmission of Burst Multicast Data

If the interval for some multicast sources to send multicast data is longer than the timeout period
of (S, G) entries, the source's DR can only encapsulate multicast data into Register messages
one by one and send the messages to the source's RP when multicast data bursts. The source's
RP transmits (S, G) information to the remote RP through SA messages. The remote RP then
sends an (S, G) Join message to the multicast source to set up an SPT. If the (S, G) entry times
out, the remote users can never receive the multicast data from the multicast source.
Filtering Policies for the Construction, Receiving, and Forwarding of SA Messages

By default, the router accepts all the SA messages that pass the RPF check, and forwards the
SA messages to other MSDP peers.
To control the transmission of SA messages among MSDP peers, you can configure filtering
policies of the construction, receiving, and forwarding of SA messages on the NE5000E.
l You can configure policies on the source's RP for filtering the multicast sources that
construct SA messages. The source's RP then filters locally registered and active multicast

sources, and determines which (S, G) information need be advertised based on the set
policies.
l You can configure policies of filtering the SA messages received from remote MSDP peers.
When SA messages sent by remote MSDP peers reach the router, the router determines
whether to accept the messages based on the set policies.
l You can configure policies of filtering the SA messages to be forwarded to remote MSDP
peers. The router then determines whether to forward the received SA messages based on
the set policies.
Multi-instance MSDP
MSDP peers can be set up between the interfaces on the routers in the same instance (public
network instance or VPN instance). MSDP peers exchange SA messages to implement inter-
domain VPN multicast.
The router running multi-instance MSDP maintains a set of MSDP mechanisms for each
supported VPN instance separately. Therefore, only the information of MSDP and PIM-SM that
belong to the same instance can be exchanged.
4.3 Configuring PIM-SM Inter-domain Multicast

connect RPs in different domains and enable RPs to share multicast source information. As a
result, hosts in the local PIM-SM domain can receive the multicast data sent by the multicast
sources in other domains.
To ensure that all RPs on a network share multicast source information and minimize the scope
of the MSDP connected graph, you are recommended to configure MSDP peers only on all RPs,
including static RPs and C-RPs on the network.
To ensure that the SA messages transmitted between MSDP peers are not interrupted by RPF
rules and to reduce redundant traffic, you are recommended to adopt the following solutions:
l Add all the MSDP peers in the same AS to the same mesh group.
l Perform one of the following steps on the MSDP peers across ASs:
Set up a TCP connection through the Boarder Gateway Protocol (BGP).
Specify the RPs as static RPF peers of each other.
Before configuring PIM-SM inter-domain multicast, complete the following tasks:
l Enabling multicast routing on all routers and enabling PIM-SM on all the interfaces
l Dividing the network into multiple PIM-SM domains and configuring RPs

Figure 4-1 Flowchart for configuring PIM-SM inter-domain multicast

Establish an MSDP peer Establish an MSDP peer
relationship between BGP relationship between static
peers RPF peers
Configure intra-AS MSDP peers Configure intra-AS MSDP peers
Configure inter-AS MSDP peers Configure inter-AS static RPF

for BGP peers peers
Mandatory
procedure
Optional
procedure
4.3.1 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 the same mesh
group.
Procedure
Step 1 Run:
system-view
Step 2 Run:
msdp [ vpn-instance vpn-instance-name ]
The MSDP view is displayed.
Step 3 Run:
peer peer-address connect-interface interface-type interface-number
An MSDP peer connection is set up.
l peer-address: specifies the address of the remote MSDP peer.

l interface-type interface-number: specifies the local interface connected with the remote
MSDP peer.

peer peer-address description text
A description is added to the remote MSDP peer.
This configuration helps you to differentiate remote MSDP peers and manage the connections
with the remote MSDP peers.


l text: specifies the description text. The text is a string of a maximum of 80 characters.
Step 5 Run:
peer peer-address mesh-group name
The remote MSDP peer is added to a mesh group. That is, the remote MSDP peer is
acknowledged as a member of the mesh group.

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 during configuration:
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 members of the mesh group.
l An MSDP peer can belong to only one mesh group. If an MSDP peer is configured to join
different mesh groups, only the latest configuration is valid.
Step 6 Run:
commit
----End
4.3.2 Configuring Inter-AS MSDP Peers for BGP Peers

You can configure an MSDP peer relationship between RPs in different ASs in which a BGP
peer relationship is set up. In this manner, PIM-SM domains in different ASs can share multicast
source information.
Context
Establish a BGP peer relationship between the RPs in different ASs and then do as follows:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
l peer-address: specifies the address of the remote MSDP peer. The address is the same as
that of the remote BGP peer.

MSDP peer. This interface is the local BGP peer interface.
A description is added to the remote MSDP peer.

This configuration helps to differentiate remote MSDP peers and manage the connections with
the remote MSDP peers.
Step 5 Run:
commit
----End
4.3.3 Configuring Inter-AS Static RPF Peers

You can configure a static RPF peer relationship between RPs in different ASs to enable PIM-
SM domains in different ASs to share multicast source information.
Context
NOTE
If "4.3.2 Configuring Inter-AS MSDP Peers for BGP Peers" is complete, skip this configuration.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:

MSDP peer.
The description is added for the remote MSDP peer is added.



Step 5 Run:
static-rpf-peer peer-address [ rp-policy ip-prefix-name ]
The remote MSDP peer is specified as a static RPF peer.

l rp-policy ip-prefix-name: specifies the policy of filtering the addresses of source's RPs in
the SA messages.
If several static RPF peers are configured for one router, obey the following configuration
rules:
Specify rp-policy for all static RPF peers.
After receiving SA messages from several active static RPF peers, the local router filters
the SA messages based on the rp-policy configured for each static RPF peer. Only the
SA messages that pass filtration are accepted.
Do not specify rp-policy for any static RPF peers
The router accepts all the SA messages received from several active static RPF peers.
Step 6 Run:
commit
----End

After PIM-SM inter-domain multicast is configured, you can run commands to check brief and
detailed information about MSDP peers.
Prerequisite
All the configurations about PIM-SM inter-domain multicast are complete.
Procedure
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] brief command
to check brief information about MSDP peers.
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] peer-status
[ peer-address ] command to check detailed information about MSDP peers.
----End
Example
Run the display msdp brief command, and you can view brief information about all the remote
MSDP peers, including the number of MSDP peers, MSDP peer addresses, and MSDP
connection status. For example:
<HUAWEI> display msdp brief
MSDP Peer Brief Information of VPN-Instance: public net
Configured Up Listen Connect Shutdown Down
2 2 0 0 0 0

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

192.168.2.1 Up 01:07:08 200 8 0
192.168.4.2 Up 00:06:39 100 13 0
Run the display msdp peer-status [ peer-address ] command, and you can view detailed
information about all the remote peers or the specified MSDP peer. For example:
<HUAWEI> display msdp peer-status 10.110.11.11
MSDP Peer Information of VPN-Instance: public net
MSDP Peer 20.20.20.20, AS 100
Description:
Information about connection status:
State: Up
Up/down time: 14:41:08
Resets: 0
Connection interface: LoopBack0 (20.20.20.30)
Number of sent/received messages: 867/947
Number of discarded output messages: 0
Elapsed time since last connection or counters clear: 14:42:40
Information about (Source, Group)-based SA filtering policy:
Import policy: none
Export policy: none
Information about SA-Requests:
Policy to accept SA-Request messages: none
Sending SA-Requests status: disable
Minimum TTL to forward SA with encapsulated data: 0
SAs learned from this peer: 0, SA-cache maximum for the peer: none
Input queue size: 0, Output queue size: 0
Counters for MSDP message:
Count of RPF check failure: 0
Incoming/outgoing SA messages: 0/0
Incoming/outgoing SA requests: 0/0
Incoming/outgoing SA responses: 0/0
Incoming/outgoing data packets: 0/0
Peer authentication: none
4.4 Configuring Anycast RP

Anycast RP indicates that multiple RPs with the same address reside in the same PIM-SM
domain and MSDP peer relationships are set up between these RPs; therefore IP routing
automatically selects the topologically closest RP for each source and receiver. This reduces
burdens on a single RP, implements RP backup, and optimizes the forwarding path.
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, The following problems may occur:
l The load of the RP is too heavy.

l Routes converge slowly after the RP fails.
l The multicast forwarding path is not optimal.
Compared with the traditional PIM-SM network, the multicast network deployed with anycast
RP has the following advantages:
l RP load balancing
Each RP maintains only partial source/group information in the PIM-SM domain, and
forwards partial multicast data.

l RP redundancy
After an RP fails, the multicast sources that register with it and the receivers that join it
select another near RP to register with and join.
l RP optimal path
Receivers send Join messages to the nearest RP. The RPT with the optimal path is thus
set up.
Multicast sources register with the nearest RP. The source tree with the optimal path is
thus set up.
Before configuring anycast RP, complete the following tasks:
l Enabling multicast routing on all routers and enable PIM-SM on all the interfaces
l Configuring a PIM-SM domain without any RP
Figure 4-2 Flowchart for configuring anycast RP
Configure the RP address on a

loopback interface
Configure a loopback interface

as an RP
Configure MSDP peers on RPs
Specify a logical RP address

for SA messages
Mandatory
procedure
Optional
procedure
4.4.1 Configuring the RP Address on a Loopback Interface

Before configuring anycast RP on the routers in a PIM-SM domain, you need to prepare a
loopback interface on each router and assign the same IP address to the loopback interfaces. In
addition, advertise the RP address through unicast routes to ensure that each router has a
reachable route to the RP address.

Procedure
Step 1 Run:
system-view
Step 2 Run:
interface loopback interface-number
The loopback interface view is displayed.
In anycast RP, multiple RPs need to use the same IP address on a network. Therefore, it is
recommended to configure loopback interfaces as RPs.
Step 3 Run:
ip address ip-address { mask | mask-length }
The address of the loopback interface, that is, the RP address, is configured.

pim sm
PIM-SM is enabled on the RP interface.
NOTE
You need run this command before configuring C-RPs. When you configure static RPs, this command is
not required.
Step 5 Run:
commit
----End
4.4.2 Configuring a Loopback Interface as an RP

You can configure a loopback interface as either a static RP or a C-RP. To configure a static RP,
you need to perform the configuration on all the routers in the PIM-SM domain; to configure a
C-RP, you need to perform the configuration only on the routers where anycast RP is to be
configured.
Procedure
l Configuring a static RP
1. Run:
system-view

2. Run:

3. Run:
static-rp rp-address

The loopback interface address is configured as a static RP address.

4. Run:
commit

l Configuring a C-RP
Before configuration, you need to configure a C-BSR and a BSR boundary. The C-BSR
address must be different from the C-RP address.
1. Run:
system-view

2. Run:

3. Run:
c-rp loopback interface-number
The loopback interface address is configured as a C-RP address.

4. Run:
commit
----End
4.4.3 Configuring MSDP Peers on RPs

MSDP peer relationships need be set up between RPs. If there are more than three routers, MSDP
peer relationships should be set up between any two routers and all MSDP peers should be added
to one mesh group.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:

MSDP peer.


The description is added for the remote MSDP peer is added.


peer peer-address mesh-group name
The 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.
NOTE
If only two routers are configured with 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 during configuration:
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.
Step 6 Run:
commit
----End
4.4.4 Specifying a Logical RP Address for SA Messages

An MSDP peer performs the RPF check on received SA messages. 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 the SA messages on the
router on which anycast RP is to be configured.
Procedure
Step 1 Run:
system-view
Step 2 Run:

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 MSDP peer interface as a logical interface.
After the originating-rp command is used, the SA message sent by the router will carry the
logical RP address. The logical RP address then replaces the RP address in the IP header of the
SA message. In this manner, the SA message can pass the RPF check after reaching the remote
router.
Step 4 Run:
commit
----End

After anycast RP in a PIM-SM domain is configured, you can run commands to check brief and
detailed information about MSDP peers and RP information of PIM routing entries.
Prerequisite
All the configurations about anycast RP in a PIM-SM domain are complete.
Procedure
command to check information about the RP of PIM routing entries.
----End
Example
Run the display msdp brief command, and you can view brief information about MSDP peers.
For example:

1 1 0 0 0 0

2.2.2.2 Up 00:10:17 ? 0 0
information about all the MSDP peers or the specified MSDP peer. For example:
MSDP Peer 20.20.20.20, AS 100
Description:


State: Up
Resets: 0
Import policy: none
Export policy: none
Run the display pim [ vpn-instance vpn-instance-name | all-instance ] routing-table command

on each RP to check information about the RP of PIM routing entries.
(10.11.1.2, 225.1.1.1)
RP: 7.7.7.7 (local)
UpTime: 00:01:57
Protocol: pim-sm, UpTime: - , Expires: -
4.5 Controlling MSDP Peer Connections

MSDP peers communicate through TCP connections. You can flexibly control the sessions set
up between MSDP peers by closing or reestablishing TCP connections. In addition, you can also
adjust the period for retrying to set up MSDP peer connections and configure MSDP peer
authentication to improve the security of TCP connections.
The router can work normally with default control parameters. You are allowed to adjust the
period for retrying to set up MSDP peer connections according to specific networking
environments.
NOTE
Before configuring MSDP peer connection control, complete the following tasks:

l Configuring PIM-SM Inter-domain Multicast or configuring Anycast RP
4.5.1 Closing an MSDP Peer Connection

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 reestablish the connection between
MSDP peers as required.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
shutdown peer-address
The connection with the remote MSDP peer is closed.

peer-address: specifies the address of the remote MSDP peer.
After the session with the remote MSDP peer is closed, configurations still remain. You can run
the undo shutdown peer-address command to reestablish a TCP connection with the remote
peer.
Step 4 Run:
commit
----End
4.5.2 Adjusting the Interval for Retrying to Set Up an MSDP Peer

Connection
When a new MSDP peer relationship is created, a closed MSDP peer connection is restarted, or
a faulty MSDP peer recovers, 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.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
timer retry interval
The interval for the router to send a TCP connection request to the remote MSDP peer is set.
Step 4 Run:
commit
----End
4.5.3 Configuring MSDP Peer Authentication

You can configure MSDP MD5 authentication for MSDP peers.
Procedure
l Configuring MSDP MD5 authentication
1. Run:
system-view

2. Run:

3. Run:
peer peer-address password { cipher cipher-password | simple simple-
password }
MSDP MD5 authentication is configured.
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 passwords configured on the two
ends can be of different formats. The password on one end can be in cipher text while
the password on the other end can be in plain text. The MD5 authentication password
is case sensitive and cannot contain any space.
By default, MSDP MD5 authentication is not configured.

4. Run:
commit
----End


After MSDP peer relationship control is configured, you can run commands to check brief and
detailed information about MSDP peers.
Prerequisite
All the configurations about MSDP peer relationship control are complete.
Procedure
----End
Example
Run the display msdp brief command, and you can view brief information about all the remote
peers, including information about the MSDP peers whose TCP connections are closed, and the
period during which the connections are closed. For example:
2 1 0 0 1 0

192.168.2.1 Up 01:07:08 200 8 0
192.168.4.2 Shutdown 00:06:39 100 13 0
4.6 Adjusting the Parameters of SA Messages

MSDP peers share (S, G) information by exchanging SA messages. You can configure the
capacity of the SA cache, enable the sending of SA Request messages, enable the encapsulation
of multicast data into SA messages, and create filtering policies of SA messages and SA Request
messages.
SA messages carry the following information and are transmitted among multiple RPs.
l IP address of the source's RP

l Number of (S, G) entries contained in the message
l Active (S, G) lists in the domain
Enabling the sending of SA Request message on the local RP and enabling the SA cache function
on the remote MSDP peer can shorten the time taken by a receiver to obtain multicast source
information.
l The local RP sends an SA Request message, carrying the required group address, for
obtaining the (S, G) list of this group.

l On receiving the SA Request message, the remote MSDP peer responds with an SA
Response message carrying the queried (S, G) information.
Before adjusting the parameters of SA messages, complete the following tasks:
l Configuring PIM-SM Inter-domain Multicast or configuring Anycast RP
4.6.1 Configuring an SA Cache

An SA cache is used to save (S, G) information carried in the SA messages locally. If the
router needs to receive multicast data, it directly obtains useful (S, G) information from the SA
cache. Setting the maximum number of (S, G) entries in an SA cache can prevent DoS attacks.
You are allowed to disable the SA cache function on the NE5000E.
Context
By default, the SA cache function is enabled on the router configured with an MSDP peer.
Procedure
l Setting the maximum number of (S, G) entries in an SA cache
It is recommended to perform this configuration on all MSDP peers on the network to avoid
DoS attacks.
1. Run:
system-view

2. Run:

3. Run:
peer peer-address sa-cache-maximum sa-limit
The maximum number of (S, G) entries in the SA cache is set.

sa-limit: specifies the maximum number of (S, G) entries in the SA cache. If the
set maximum number is smaller than the SA cache specification, the set value takes
effect; otherwise, the SA cache specification takes effect.
By default, an SA cache can save a maximum of 8192 (S, G) entries.
4. Run:
commit


l Disabling the SA cache function
1. Run:
system-view

2. Run:

3. Run:
undo cache-sa-enable
The SA cache function is disabled.

After the SA cache function is disabled, an RP directly forwards the received SA
messages to remote MSDP peers. It does not save the (S, G) information carried in
the SA messages locally. If the router needs to receive multicast data, it must wait for
the SA message sent by the MSDP peer in the next sending period. This may result
in a delay in obtaining multicast source information.
You can run the cache-sa-enable command in the MSDP view to re-enable the SA
cache function.
4. Run:
commit

----End
4.6.2 Configuring Filtering Policies for SA Messages

By default, an MSDP peer accepts all the SA messages that pass the RPF check, and forwards
the SA messages to all remote MSDP peers. To control the transmission of SA messages among
MSDP peers, you can configure filtering policies of constructing, receiving, and forwarding SA
messages.
Procedure
l Configuring a filtering policy for constructing SA messages on the source 's RP
1. Run:
system-view

2. Run:

3. Run:
import-source [ acl { acl-number | acl-name } ]
The filtering policy for constructing SA messages is configured.

acl basic-acl-number: defines a filtering policy. The source's RP filters locally
registered and active multicast sources, and determines which (S, G) information need
be advertised based on the set policies.

If no ACL is specified, the SA message does not carry information about any local
active source.
If an ACL is specified, the source's RP constructs an SA message carrying
information about only the local sources matching the ACL, thereby, controlling
the advertisement of local (S, G) information.
By default, the source's RP constructs an SA message carrying information about all
the local active sources.
4. Run:
commit

l Configuring a filtering policy for receiving SA messages from remote MSDP peers
1. Run:
system-view

2. Run:

3. Run:
peer peer-address sa-policy import [ acl { advanced-acl-number | acl-name
acl-name } ]
The filtering policy for receiving SA messages from remote MSDP peers is set.
acl advanced-acl-number: defines a filtering policy. When the SA message sent by a
remote MSDP peer reaches the router, the router determines whether to accept the
message based on the set policy.
If no ACL is specified, the router does not accept any (S, G) information received
from peer-address.
If an ACL is specified, the router accepts the (S, G) information received from
peer-address and passing the filtration.
By default, the router accepts all the SA messages that pass the RPF check.
4. Run:
commit

l Configuring a filtering policy for forwarding SA messages to remote MSDP peers
1. Run:
system-view

2. Run:

3. Run:
peer peer-address sa-policy export [ acl { advanced-acl-number | acl-name
acl-name } ]

The filtering policy for forwarding SA messages to remote MSDP peers is configured.
acl advanced-acl-number: defines a filtering policy. The router determines whether
to forward the received SA messages based on the set policy.
If no ACL is specified, the router does not forward any (S, G) information to peer-
address.
If an ACL is specified, the router forwards only the (S, G) information passing the
filtration to peer-address.
By default, the router forwards all the SA messages that pass the RPF check.
4. Run:
commit

----End

After SA message parameters are adjusted, you can run commands to check information and the
number of (S, G) entries in the SA cache and view details about MSDP peers.
Prerequisite
SA message parameters are adjusted as required.
Procedure
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] sa-cache [ group-
address | source-address | as-number ] * command to check information about (S, G) entries
in the SA cache.
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] sa-count [ as-
number ] command to check the number of (S, G) entries in the SA cache.
----End
Example
Run the display msdp sa-cache command, and you can view information about the (S, G) entries
in the SA cache. For example:
<HUAWEI> display msdp sa-cache
MSDP Source-Active Cache Information of VPN-Instance: public net
MSDP Total Source-Active Cache - 2 entries
MSDP matched 2 entries
(20.0.5.120, 225.0.0.1)
Origin RP: 3.3.3.3
Pro: ?, AS: ?
Uptime: 00:01:01, Expires: 00:05:59
(20.0.5.120, 225.0.0.2)
Origin RP: 3.3.3.3

Pro: ?, AS: ?
Uptime: 00:00:01, Expires: 00:05:59
Run the display msdp sa-count command, and you can view the number of (S, G) entries in
the SA cache. The entries are counted based on the numbers of the ASs where MSDP peers and
RPs reside. For example:
<HUAWEI> display msdp sa-count
MSDP Source-Active Count Information of VPN-Instance: public net
Number of cached Source-Active entries, counted by Peer
Peer's Address Number of SA
10.10.10.10 5
Number of source and group, counted by AS
AS Number of source Number of group
? 3 3
Total 5 Source-Active entries matched
information about all the remote peers or the specified MSDP peer.
l You can view the setting of the maximum number of (S, G) entries in the SA cache from
the "SA-cache maximum for the peer" field.
l You can view the configuration of SA Request messages from the "Information about SA-
Requests" field.
l You can view the setting of the TTL threshold of the SA messages with multicast data
encapsulated from the "Minimum TTL to forward SA with encapsulated data" field.
l You can view the configuration of filtering policies of SA messages from the "Information
about (Source, Group)-based SA filtering policy" field.
For example:
MSDP Peer 20.20.20.20, AS 100
Description:
State: Up
Resets: 0
Import policy: 3000
Export policy: 3002
Policy to accept SA-Request messages: 2000
Sending SA-Requests status: enable
SAs learned from this peer: 0, SA-cache maximum for the peer: 5000

4.7 Maintaining MSDP

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

When you clear statistics about MSDP peers, you can choose whether to reset the TCP
connection between MSDP peers as required. The statistics cannot be restored after being
cleared. Resetting the TCP connection will affect the MSDP running.
Context
CAUTION
The statistics about MSDP peers cannot be restored after being cleared. So, confirm the action
before you use the command.
Procedure
l After resetting the TCP connection with the specified MSDP peer and clearing the statistics
about the specified MSDP peer are confirmed, run the reset msdp [ vpn-instance vpn-
instance-name | all-instance ] peer [ peer-address ] command in the user view.
l After clearing the statistics about one or multiple MSDP peers without resetting the TCP
connection with the MSDP peer(s) is confirmed, run the reset msdp [ vpn-instance vpn-
instance-name | all-instance ] statistics [ peer-address ] command in the user view.
l Run the reset msdp [ vpn-instance vpn-instance-name | all-instance ] control-message
counters [ peer peer-address ] command in the user view to clear the statistics about the
received, sent, and discarded MSDP messages.
----End
4.7.2 Clearing (S, G) Information from an SA Cache

If you want to reset the contents in an SA cache, you can clear all (S, G) information from the
SA cache. (S, G) information cannot be restored after being cleared.
Context
CAUTION
(S, G) information in an SA Cache cannot be restored after you clear it. So, confirm the action
before you use the command.

Procedure
Step 1 After clearing the (S, G) information from an SA cache is confirmed, run the reset msdp [ vpn-
instance vpn-instance-name | all-instance ] sa-cache [ group-address ] command in the user
view.
----End
4.7.3 Monitoring the Running Status of MSDP

You can monitor the running status of MSDP by checking brief and detailed information about
MSDP peers, (S, G) information in the SA cache, and the number of (S, G) entries in the SA
cache.
Context
During the routine maintenance, you can run the following commands in any view to know the
running status of MSDP.
Procedure
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] brief [ state
{ connect | down | listen | shutdown | up } ] command in any view to check brief
information about MSDP peers.
[ peer-address ] command in any view to check detailed information about MSDP peers.
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] sa-cache [ group-
address | source-address | as-number ] * command in any view to check (S, G) information
in the SA cache.
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] sa-count [ as-
number ] command in any view to check the number of (S, G) entries in the SA cache.
l Run the display msdp [ vpn-instance vpn-instance-name | all-instance ] control-
message counters [ peer peer-address | message-type { source-active | sa-request | sa-
response | keepalive | notification | traceroute-request | traceroute-reply | data-
packets | unknown-type } ] * command in any view to check statistics about the received,
sent, and discarded MSDP messages.
----End

Configuration examples are provided to tell you how to implement the MSDP RPF check through
BGP or static RPF neighbors, how to implement PIM-SM inter-domain multicast, inter-AS
multicast, and how to configure anycast RP in a PIM-SM domain.
4.8.1 Example for Configuring PIM-SM Inter-domain Multicast

You can set up MSDP peer relationships between RPs in different PIM-SM domains in the same
AS or between the RPs in different ASs that have set up BGP peer relationships so that hosts
can receive multicast data from the source in another PIM-SM domain in the AS or from the
source in another AS.

CAUTION
As shown in Figure 4-3, there are two ASs on the network. Each AS contains at least one PIM-
SM domain and each PIM-SM domain may contain none or one multicast source and receiver.
It is required that the receiver in PIM-SM2 domain be capable of receiving both the multicast
data sent by S3 in PIM-SM3 domain and the multicast data sent by S1 in PIM-SM1 domain.
Figure 4-3 Networking diagram of configuring PIM-SM inter-domain multicast
AS100 AS200
Loopback0
Loopback0 2.2.2.2/32 Receiver
1.1.1.1/32
PIM-SM2
RouterA
RouterC GE1/0/0
POS2/0/0 POS1/0/0 POS1/0/0 POS2/0/0
POS2/0/0 POS2/0/0
GE1/0/0 RouterB POS3/0/0 RouteD
PIM-SM1
S1 POS3/0/0 RouterF
POS2/0/0
POS2/0/0
RouterE GE1/0/0
PIM-SM3
S3
Loopback0
3.3.3.3/32
MSDP peer

Router A GE 1/0/0 10.110.1.1/24 Router D GE 1/0/0 10.110.2.1/24
POS 2/0/0 192.168.1.1/24 POS 2/0/0 192.168.3.2/24
Router B POS 1/0/0 192.168.2.1/24 Router E POS 2/0/0 192.168.5.1/24
POS 2/0/0 192.168.1.2/24 POS 3/0/0 192.168.4.2/24
Router C POS 1/0/0 192.168.2.2/24 Router F GE 1/0/0 10.110.3.1/24
POS 2/0/0 192.168.3.1/24 POS 2/0/0 192.168.5.2/24
POS 3/0/0 192.168.4.1/24

Configuration Notes
When configuring PIM-SM inter-domain multicast, pay attention to the following points:
l Establishing an MSDP peer relationship between BGP peers is applicable to only the
situation when the RP and the unicast ASBR are configured on the same router.
l The address of the interface on which the MSDP peer is configured must be the same with
that of the interface on which the EBGP peer is configured.
You need to establish MSDP peer relationships between RPs in PIM-SM domains. The
configuration roadmap is as follows:
1. Configure IP addresses for the interfaces on each router, and configure OSPF in the ASs
to ensure that unicast routes are reachable in the ASs.
2. Establish an EBGP peer relationship between ASs and configure BGP and OSPF to import
routes from each other to ensure that unicast routes are reachable between ASs.
3. Enable the multicast function, enable PIM-SM on each interface, configure BSR boundaries
to divide PIM-SM domains, and enable IGMP on the interface connected with the host.
4. Configure the C-BSR and the C-RP. Configure the RPs of PIM-SM1 and PIM-SM2 on the
ASBRs in the two domains.
5. Establish MSDP peer relationships between RPs of PIM-SM domains.
6. Add MSDP peers in the same AS to the same mesh group.
Data Preparation
l AS numbers of Router A and Router B and router ID of Router B
l AS numbers of Router C and Router D and router ID of Router C
l AS numbers of Router E and Router F
l Name of the mesh group to which MSDP peers in AS 200 join
Procedure
Step 1 Configure IP addresses for the interfaces on each router, and configure OSPF in the ASs. The
detailed configuration procedure is not mentioned here.
Step 2 Establish an EBGP peer relationship between ASs and configure BGP and OSPF to import routes
from each other.
# Configure EBGP on Router B and import OSPF routes.
[~RouterB] bgp 100
[~RouterB-bgp] router-id 1.1.1.1
[~RouterB-bgp] peer 192.168.2.2 as-number 200
[~RouterB-bgp] import-route ospf 1
[~RouterB-bgp] commit
[~RouterB-bgp] quit

# Configure EBGP on Router C and import OSPF routes.

[~RouterC] bgp 200
[~RouterC-bgp] router-id 2.2.2.2
[~RouterC-bgp] peer 192.168.2.1 as-number 100
[~RouterC-bgp] import-route ospf 1
[~RouterC-bgp] commit
[~RouterC-bgp] quit
# Import BGP routes to OSPF on Router B. The configuration of Router C is similar to that of
Router B, and is not mentioned here.
[~RouterB] ospf 1
[~RouterB-ospf-1] import-route bgp
[~RouterB-ospf-1] commit
[~RouterB-ospf-1] quit
Step 3 Enable the multicast function, enable PIM-SM on interfaces, and configure BSR boundaries.
# Enable the multicast function on Router B and enable PIM-SM on each interface. The
configurations on other routers are similar to those on router B and are not mentioned here.
[~RouterB] multicast routing-enable
[~RouterB] interface pos 2/0/0
[~RouterB-Pos2/0/0] pim sm
[~RouterB-Pos2/0/0] quit
[~RouterB-Pos1/0/0] commit
# Configure a BSR boundary on POS 1/0/0 on Router B, POS 3/0/0 on Router E, and POS 1/0/0
and POS 3/0/0 on Router C respectively. The configurations on Router E and Router C are similar
to those on Router B and are not mentioned here.
[~RouterB-Pos1/0/0] pim bsr-boundary

# Enable IGMP on the interface connecting Router D to hosts.
Step 5 Configure the C-BSR and the C-RP.

# Create loopback 0 on Router B and configure loopback 0 as both a C-BSR and a C-RP. The
configurations on Router C andRouter E are similar to those on Router B and are not mentioned
here.
[~RouterB] interface loopback 0
[~RouterB-LoopBack0] ip address 1.1.1.1 255.255.255.255
[~RouterB-LoopBack0] pim sm
[~RouterB-LoopBack0] quit
[~RouterB] pim
[~RouterB-pim] c-bsr loopback 0
[~RouterB-pim] c-rp loopback 0
[~RouterB-pim] commit
[~RouterB-pim] quit
Step 6 Establish MSDP peer relationships.

# Configure an MSDP peer on Router B.
[~RouterB] msdp

[~RouterB-msdp] peer 192.168.2.2 connect-interface pos1/0/0

[~RouterB-msdp] commit
[~RouterB-msdp] quit
# Configure an MSDP peer on Router C.

[~RouterC] msdp
[~RouterC-msdp] peer 192.168.2.1 connect-interface pos1/0/0
[~RouterC-msdp] peer 192.168.4.2 connect-interface pos3/0/0
[~RouterC-msdp] commit
[~RouterC-msdp] quit
# Configure an MSDP peer on Router E.

[~RouterE] msdp
[~RouterE-msdp] peer 192.168.4.1 connect-interface pos3/0/0
[~RouterE-msdp] commit
[~RouterE-msdp] quit
Step 7 Add MSDP peers in the same AS to the same mesh group.
# Add Router C to the mesh group as200.
[~RouterC] msdp
[~RouterC-msdp] peer 192.168.4.2 mesh-group as200
# Add Router E to the mesh group as200.

[~RouterE] msdp
[~RouterE-msdp] peer 192.168.4.1 mesh-group as200
[~RouterE-msdp] commit
[~RouterE-msdp] quit

# Run the display bgp peer command, and you can view BGP peer relationships established
between routers. For example, the BGP peer relationship between Router B and Router C is
displayed as follows:
<RouterB> 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 52 49 0 00:42:37 Established 7
# Run the display bgp routing-table command, and you can view BGP routing tables
onrouters. For example, the BGP routing table on Router C is displayed as follows:
<RouterC> display bgp routing-table
Total Number of Routes: 10
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?

*> 2.2.2.2/32 0.0.0.0 0 0 ?
*> 3.3.3.3/32 0.0.0.0 1 0 ?
*> 10.110.1.0/24 192.168.2.1 2 0 100?
*> 10.110.2.0/24 0.0.0.0 2 0 ?
*> 10.110.3.0/24 0.0.0.0 3 0 ?

*> 192.168.1.0 192.168.2.1 1 0 100?

*> 192.168.3.0 0.0.0.0 1 0 ?
*> 192.168.4.0 0.0.0.0 1 0 ?
*> 192.168.5.0 0.0.0.0 2 0 ?
# Run the display msdp brief command, and you can view MSDP peer relationships established
between routers. The brief information about MSDP peer relationships established between
Router B and Router C and Router E is displayed as follows:
<RouterB> display msdp brief
1 1 0 0 0 0
192.168.2.2 Up 00:12:27 200 13 0
<RouterC> 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
<RouterE> 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, and you can view detailed information about
MSDP peer relationships established between routers. The detailed information about MSDP
peer relationships on Router B is displayed as follows:
<RouterB> display msdp peer-status
MSDP Peer 192.168.2.2, AS 200
Description:
State: Up
Resets: 0
Connection interface: Pos1/0/0 (192.168.2.1)
Import policy: none
Export policy: none
Peer authentication: unconfigured
# Run the display pim routing-table command, and you can view PIM routing tables on
routers. When S1 (10.110.1.2/24) in PIM-SM1 domain and S3 (10.110.3.2/24) in PIM-SM3
domain send multicast data to G (225.1.1.1/24), Receiver (10.110.2.2/24) in PIM-SM2 domain
can receive the multicast data. Information about the PIM routing tables on Router B and
Router C is as follows:

<RouterB> 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: Pos1/0/0
(*, 225.1.1.1)
RP: 2.2.2.2 (local)
Protocol: pim-sm, Flag: WC RPT
UpTime: 00:13:46
Upstream interface: NULL
1: Pos2/0/0,
(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: Pos2/0/0
(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: Pos2/0/0
----End
Configuration Files
#
sysname RouterB
#
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Pos1/0/0

undo shutdown
link-protocol ppp
ip address 192.168.2.1 255.255.255.0
pim bsr-boundary
pim sm
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
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
#
bgp 100
router-id 1.1.1.1
peer 192.168.2.2 as-number 200
#
ipv4-family unicast
import-route ospf 1
peer 192.168.2.2 enable
peer 192.168.2.2 route-update-interval 0
#
msdp
peer 192.168.2.2 connect-interface Pos1/0/0
#
return
#
sysname RouterC
#
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.2.2 255.255.255.0
pim bsr-boundary
pim sm
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 192.168.4.1 255.255.255.0
pim bsr-boundary
pim sm
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
pim sm
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
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
#
bgp 200
router-id 2.2.2.2
#
ipv4-family unicast
import-route ospf 1
peer 192.168.2.1 route-update-interval 0
#
msdp
peer 192.168.4.2 mesh-group as200
#
return

#
sysname RouterE
#
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.5.1 255.255.255.0
pim sm
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 192.168.4.2 255.255.255.0
pim bsr-boundary
pim sm
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
pim sm
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
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
#
msdp
peer 192.168.4.1 mesh-group as200
#
return
4.8.2 Example for Configuring Inter-AS Multicast by Using Static

RPF Peers
You can set up MSDP peer relationships between RPs in different PIM-SM domains in the same
AS or static RPF relationships between the RPs in different ASs so that hosts can receive
multicast data from the source in another PIM-SM domain in the AS or from the source in another
AS.

CAUTION
As shown in Figure 4-4, there are two ASs on the network. Each AS contains at least one PIM-
SM domain and each PIM-SM domain may contain no or one multicast source and receiver. It
is required that the receiver in PIM-SM2 domain be capable of receiving both the multicast data
sent by S3 in PIM-SM3 domain and the multicast data sent by S1 in PIM-SM1 domain without
changing the unicast topology.
Figure 4-4 Networking diagram for configuring inter-AS multicast by using static RPF peers
AS100 AS200
Loopback0
RouterE
POS2/0/0 POS1/0/0
Loopback0
RouterD
RouterC POS2/0/0 PIM-SM2
POS1/0/0
Receiver
100
Receiver
POS2/0/0 PIM-SM1 RouterB Loopback0
RouterG
POS1/0/0
S1
POS1/0/0
RouterA RouterF
PIM-SM3
S2
BGP peers

Router B POS 2/0/0 192.168.2.2/24 Loopback0 2.2.2.2/32
Router C POS 1/0/0 192.168.1.1/24 Router E POS 2/0/0 192.168.2.1/24
POS 2/0/0 192.168.4.1/24 Router F POS 1/0/0 192.168.5.1/24
Loopback 0 1.1.1.1/32 Loopback 0 3.3.3.3/32

Configuration Notes
When configuring inter-AS multicast by using static RPF peers, pay attention to the following
points:
l Incorrect configuration of static RPF peers may cause a routing loop of SA messages. So,
configure static RPF peers with caution.
You need to establish MSDP peer relationships between RPs in PIM-SM domains and then
configure static RPF peers for MSDP peers. The configuration roadmap is as follows: The RPF
check is not required for the SA messages sent from a static RPF peer, thereby implementing
multicast source information sharing between ASs without changing the unicast topology.
1. Configure IP addresses for the interfaces on each router; configure OSPF in each AS and
configure EBGP between ASs; configure BGP and OSPF to import routes from each other.
2. Enable the multicast function on and enable PIM-SM on each interface. Configure loopback
0 as both a C-BSR and a C-RP: Loopback 0 interfaces on Router C, Router D, and
Router F function as the C-BSRs and the C-RPs for the PIM-SM domains where they
separately reside.
3. Establish an MSDP peer relationship between RPs in PIM-SM domains: Establish MSDP
peer relationships between Router C and Router D, and between Router C and Router F.
4. Specify static RPF peers for MSDP peers: Specify Router D and Router F as static RPF
peers of Router C. Specify Router C as the only static RPF peer for Router D and Router
F separately.
Data Preparation
l AS numbers and router IDs of Router A, Router B, and Router C
l AS numbers and router IDs of Router D and Router E
l AS numbers of Router F and Router G, router ID of Router F
l Policy used by Router C to filter the SA messages received from Router D and Router F
l Policy used by Router D and Router F to filter the SA messages received from Router C
Procedure
Step 1 Configure IP addresses for the interfaces on each router, and configure OSPF in the ASs. The
detailed configuration procedure is not mentioned here.
Step 2 Enable the multicast function on and enable PIM-SM on interfaces.
# Enable the multicast function on all routers and enable PIM-SM on each interface. The
configurations on other routers are similar to those on router C and are not mentioned here.
[~RouterC] multicast routing-enable
[~RouterC] interface pos 1/0/0
[~RouterC-Pos1/0/0] pim sm
[~RouterC-Pos1/0/0] quit

[~RouterC-Pos2/0/0] commit
# Configure a BSR boundary on POS 1/0/0 on Router A and Router F, and POS 2/0/0 on
Router B and Router E respectively. The configurations on Router B, Router E, and Router F
are similar to those on Router A and are not mentioned here.
[~RouterA-Pos1/0/0] pim bsr-boundary
Step 3 Enable IGMP on the interfaces connected to hosts. The detailed configuration procedure is not
mentioned here.
Step 4 Configure loopback 0 as both a C-BSR and a C-RP.
# Create loopback 0 interfaces on Router C, Router D, and Router F, and configure loopback 0
as both a C-BSR and a C-RP on each Router. The configurations on Router D andRouter F are
similar to those on Router C and are not mentioned here.
[~RouterC] interface loopback 0
[~RouterC-LoopBack0] ip address 1.1.1.1 255.255.255.255
[~RouterC-LoopBack0] pim sm
[~RouterC-LoopBack0] quit
[~RouterC] pim
[~RouterC-pim] c-bsr loopback 0
[~RouterC-pim] c-rp loopback 0
[~RouterC-pim] commit
[~RouterC-pim] quit
Step 5 Configure static RPF peers.

# Configure Router D and Router F as static RPF peers of Router C.
[~RouterC] ip ip-prefix list-df permit 192.168.0.0 16 greater-equal 16 less-equal
32
[~RouterC] msdp
[~RouterC-msdp] peer 192.168.3.2 connect-interface pos 1/0/0
[~RouterC-msdp] peer 192.168.5.1 connect-interface pos 2/0/0
[~RouterC-msdp] static-rpf-peer 192.168.3.2 rp-policy list-df
[~RouterC-msdp] static-rpf-peer 192.168.5.1 rp-policy list-df
# Configure Router C as static RPF peers of Router D and Router F respectively. The
configurations on Router F andRouter D are similar and are not mentioned here.
[~RouterD] ip ip-prefix list-c permit 192.168.0.0 16 greater-equal 16 less-equal 32
[~RouterD] msdp
[~RouterD-msdp] peer 192.168.1.1 connect-interface pos 1/0/0
[~RouterD-msdp] static-rpf-peer 192.168.1.1 rp-policy list-c
[~RouterD-msdp] commit
[~RouterD-msdp] quit

# Run the display bgp peer command, and you can view BGP peer relationships established
between routers. Router C has no output, which indicates that the BGP peer relationships are
not set up between Router C and Router D, and between Router C and Router F.
between routers. When S1 in PIM-SM1 domain sends multicast data, the receivers in PIM-SM2
and PIM-SM3 domains can receive the data. For example, display of MSDP peers on Router C,
Router D, and Router F is as follows:

<RouterC> display msdp brief

2 2 0 0 0 0
192.168.3.2 Up 01:07:08 ? 8 0
192.168.5.1 Up 00:16:39 ? 13 0
<RouterD> display msdp brief
1 1 0 0 0 0
192.168.1.1 Up 01:07:09 ? 8 0
<RouterF> display msdp brief
1 1 0 0 0 0
192.168.4.1 Up 00:16:40 ? 13 0
----End
Configuration Files
#
sysname RouterC
#
ip ip-prefix list-df index 10 permit 192.168.0.0 16 greater-equal 16 less-equal
32
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.4.1 255.255.255.0
pim sm
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
network 1.1.1.1 0.0.0.0
#
msdp
peer 192.168.3.2 connect-interface pos 1/0/0
static-rpf-peer 192.168.3.2 rp-policy list-df
static-rpf-peer 192.168.5.1 rp-policy list-df
#
return

#

sysname RouterD
#
ip ip-prefix list-c index 10 permit 192.168.0.0 16 greater-equal 16 less-equal
32
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
pim sm
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
ospf 1
area 0.0.0.0
network 192.168.3.0 0.0.0.255
network 2.2.2.2 0.0.0.0
#
msdp
static-rpf-peer 192.168.1.1 rp-policy list-c
#
return
l Configuration file of the Router F

#
sysname RouterF
#
ip ip-prefix list-c index 10 permit 192.168.0.0 16 greater-equal 16 less-equal
32
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
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
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
ospf 1
area 0.0.0.0
network 192.168.5.0 0.0.0.255
network 3.3.3.3 0.0.0.0
#
msdp
static-rpf-peer 192.168.4.1 rp-policy list-c
#
return
4.8.3 Example for Configuring Anycast RP

If there are multiple multicast sources and receivers in a PIM-SM domain, you can configure
MSDP peer relationships between C-RPs and configure anycast RP to implement load sharing.

CAUTION
As shown in Figure 4-5, the PIM-SM domain has multiple multicast sources and receivers. It
is required that MSDP peers be established in the PIM-SM domain to implement RP load
balancing.
Figure 4-5 Networking diagram of configuring anycast RP
Receiver
Host2 RouterB
GE2/0/0
RouterF Loopback10
GE1/0/0
Source PIM-SM GE3/0/0 GE2/0/0
S1 RouterD
Loopback1
POS1/0/0
Source
GE1/0/0
S2
RouterA Loopback0
GE2/0/0 Loopback0
POS1/0/0
GE2/0/0
POS1/0/0
Loopback1
GE3/0/0 POS2/0/0
RouterC RouterE
RouterG
Loopback10
Receiver
Host1
MSDP peers

Router A GE 1/0/0 10.110.5.1/24 Router D POS 1/0/0 192.168.3.1/24
GE 2/0/0 10.110.1.2/24 GE 2/0/0 10.110.2.1/24
Router B GE 1/0/0 10.110.6.1/24 GE 3/0/0 10.110.3.1/24
GE 2/0/0 10.110.2.2/24 Loopback 0 2.2.2.2/32
RouterC POS 1/0/0 192.168.1.1/24 Loopback 1 4.4.4.4/32
GE 2/0/0 10.110.1.1/24 Loopback 10 10.1.1.1/32
GE 3/0/0 10.110.4.1/24 RouterE POS 1/0/0 192.168.3.2/24
Loopback 0 1.1.1.1/32 POS 2/0/0 192.168.1.2/24

Loopback 1 3.3.3.3/32
Loopback10 10.1.1.1/32
Configuration Notes
When configuring anycast RP, pay attention to the following points:
l You need to configure RPs on loopback interfaces.
l Before configuring loopback interfaces as C-RPs, enable PIM-SM on the loopback
interfaces. Before configuring C-RPs, configure C-BSRs and BSR boundaries. The C-BSR
addresses cannot be the same as the addresses of the local C-RPs.
Configure anycast RP so that the receiver can send a Join message to the closest RP and the
source can send a Register message to the closest RP. In this way, RP load sharing is
implemented. The configuration roadmap is as follows:
1. Configure IP addresses for the interfaces on each router and configure OSPF in the PIM-
SM to ensure communications between routers in the domain.
2. Enable the multicast function, enable PIM-SM on each interface, and enable IGMP on the
interface at the host side.
3. Configure the same address for loopback 10 interfaces on Router C and Router D and
configure the loopback 10 interfaces on them as C-RPs; configure loopback 1 interfaces as
C-BSRs.
4. Configure MSDP peers on loopback 0 interfaces of Router C and Router D separately.
MSDP accepts the SA messages received from the source's RP based on the RPF rules.
Data Preparation
l Router ID of Router C
l Router ID of Router D
Procedure
Step 1 Configure an IP address for each interface and a unicast routing protocol.on the routers. The
configuration details are not mentioned here.
# Configure an IP address and mask to each interface according to Figure 4-5 in the PIM-SM
domain and configure OSPF to ensure the communications between routers. The detailed
configuration procedure is not mentioned here.
Step 2 Enable the multicast function on and enable PIM-SM on interfaces.
# Enable the multicast function on all routers and enable PIM-SM on each interface. The
configurations on other routers are similar to those on Router C and are not mentioned here.


[~RouterC-GigabitEthernet3/0/0] pim sm
[~RouterC-Pos1/0/0] commit
Step 3 Enable IGMP on the interfaces connected to hosts. The detailed configuration procedure is not
mentioned here.
Step 4 Configure loopback 1 and loopback 10 interfaces and configure C-BSRs and C-RPs.
# Configure the same address for loopback 1 interfaces and the same address for loopback 10
interfaces on Router C and Router D; configure loopback 1 interfaces as C-BSRs and loopback
10 interfaces as C-RPs. The configurations on Router D are similar to those on Router C and
[~RouterC] pim
[~RouterC-pim] c-bsr loopback 1
[~RouterC-pim] c-rp loopback 10
[~RouterC-pim] commit
[~RouterC-pim] quit
Step 5 Configure loopback 0 interfaces and MSDP peers.

# Configure an MSDP peer on loopback 0 on Router C.
[~RouterC] msdp
[~RouterC-msdp] originating-rp loopback0
[~RouterC-msdp] peer 2.2.2.2 connect-interface loopback0
# Configure an MSDP peer on loopback 0 on Router D.

[~RouterD] interface loopback 0
[~RouterD-LoopBack0] ip address 2.2.2.2 255.255.255.255
[~RouterD-LoopBack0] pim sm
[~RouterD-LoopBack0] commit
[~RouterD-LoopBack0] quit
[~RouterD] msdp
[~RouterD-msdp] originating-rp loopback0
[~RouterD-msdp] peer 1.1.1.1 connect-interface loopback0
[~RouterD-msdp] commit
[~RouterD-msdp] quit

between routers. The detailed information about MSDP peers on Router C and Router D is
displayed as follows:

[~RouterC] display msdp brief

1 1 0 0 0 0
2.2.2.2 Up 00:10:17 ? 0 0
[~RouterD] display msdp brief
1 1 0 0 0 0
1.1.1.1 Up 00:10:18 ? 0 0
# Run the display pim routing-table command, and you can view PIM routing tables
onrouters. In the PIM-SM domain, S1 (10.110.5.100/24) sends multicast data to G (225.1.1.1).
Host1 that joins G can receive the multicast data sent to G. By comparing the display of PIM
routes on Router C and Router D, you can find that the current valid RP is Router C. S1 registers
with Router C, and Host1 sends Join messages to Router C.
(*, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:28:49
Protocol: static, UpTime: 00:28:49, Expires: -
(10.110.5.1, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: SPT 2MSDP ACT
UpTime: 00:02:26
Protocol: pim-sm, UpTime: 00:02:26, Expires: -
There is no display.
# Host1 leaves G, and S1 stops sending multicast data to G. You can run the reset multicast
forwarding-table all command to clear the multicast routing entries on Router C.
<RouterC> reset multicast forwarding-table all
# Host2 joins G, and S2 (10.110.6.100/24) begins to send multicast data to G. By comparing

with the display of PIM routes on Router C and Router D, you can find that the current valid RP
is Router D. S2 registers with Router D, and Host2 sends Join messages to Router D.
There is no display.
(*, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: WC RPT
UpTime: 00:07:23


(10.110.6.100, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: SPT 2MSDP ACT
UpTime: 00:10:20
----End
Configuration Files
#
sysname RouterC
#
#
undo shutdown
ip address 10.110.4.1 255.255.255.0
pim sm
#
undo shutdown
ip address 10.110.1.1 255.255.255.0
pim sm
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
pim sm
#
interface LoopBack10
ip address 10.1.1.1 255.255.255.255
pim sm
#
pim
c-bsr LoopBack1
c-rp LoopBack10
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 10.110.4.0 0.0.0.255
network 1.1.1.1 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.1 0.0.0.0

network 192.168.1.0 0.0.0.255

#
msdp
originating-rp LoopBack0
peer 2.2.2.2 connect-interface LoopBack0
#
return

#
sysname RouterD
#
#
undo shutdown
ip address 10.110.3.1 255.255.255.0
pim sm
#
undo shutdown
ip address 10.110.2.1 255.255.255.0
pim sm
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
pim sm
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
pim sm
#
interface LoopBack10
ip address 10.1.1.1 255.255.255.255
pim sm
#
pim
c-bsr LoopBack1
c-rp LoopBack10
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 10.110.3.0 0.0.0.255
network 2.2.2.2 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.1.1.1 0.0.0.0
network 192.168.3.0 0.0.0.255
#
msdp
originating-rp LoopBack0
peer 1.1.1.1 connect-interface LoopBack0
#
return

Configuration Guide - IP Multicast 5 MBGP Configuration
5 MBGP Configuration
About This Chapter
Multicast BGP (MBGP) is used to transmit routing information between Autonomous Systems
(ASs) for multicast services.
5.1 MBGP Overview

MBGP is a multiprotocol extension to the Border Gateway Protocol (BGP).
5.2 MBGP Features Supported by the NE5000E
The NE5000E supports the MBGP features of load balancing, route summarization, route
dampening, community usage, and route reflector usage.
5.3 Configuring an MBGP Peer
Valid routing information can be provided for the Reverse Path Forwarding (RPF) check only
after an MBGP connection is enabled in the multicast address family view.
5.4 Configuring MBGP to Import Local Routes
MBGP can import routes from other protocols. When routes are imported from dynamic routing
protocols, the process IDs of the routing protocols must be specified.
5.5 Controlling MBGP Route Advertisement
MBGP can filter or apply routing policies to the routes to be advertised to a peer or peer group.
5.6 Controlling MBGP Route Selection
The policy governing MBGP route selection can be changed by configuring MBGP route
attributes.
5.7 Configuring MBGP Routing Policies
MBGP routing policies can be configured to flexibly control the sending and receiving of routes.
5.8 Configuring MBGP Load Balancing
Configuring MBGP load balancing better utilizes network resources.
5.9 Configuring MBGP Route Dampening
Configuring MBGP route dampening suppresses instable MBGP routes.
5.10 Configuring MBGP RRs
MBGP RRs resolve the problem of full-mesh connections between multiple IBGP peers, which
reduces network costs.

5.11 Maintaining MBGP

Maintaining MBGP involves resetting MBGP connections, clearing MBGP statistics, and
debugging MBGP.
This chapter provides an MBGP configuration example. In the configuration example, the
networking requirements, network diagram, precautions, configuration roadmap, and
configuration procedures are provided.

5.1 MBGP Overview

MBGP is a multiprotocol extension to the Border Gateway Protocol (BGP).
If a multicast source and its receivers are located in different ASs, a multicast forwarding tree
must be built across the ASs. The Multiprotocol Border Gateway Protocol (MP-BGP) can be
used to transmit routing information between ASs for multicast services.
MP-BGP is an enhanced BGP. At present, BGP4 only applies to unicast routing. Adding
capabilities to BGP4, MP-BGP allows BGP to provide routing information for multiple routing
protocols, including multicast.
l MP-BGP maintains both unicast routes and multicast routes, stores them in different routing
tables, and keeps unicast routing information and multicast routing information separate
from each other.
l MP-BGP builds a unicast routing topology different from a multicast routing topology.
l Most of unicast routing policies and configuration methods supported by BGP4 can be
applied to multicast, and MP-BGP maintains unicast routes different from multicast routes
based on the routing policies.
When MP-BGP is applied to multicast, it is called MBGP.
NOTE
This chapter describes MP-BGP configurations for multicast, namely, MBGP configurations. For more
information about MP-BGP, see the HUAWEI NetEngine5000E Core Router Configuration Guide - IP
Routing.
5.2 MBGP Features Supported by the NE5000E

The NE5000E supports the MBGP features of load balancing, route summarization, route
dampening, community usage, and route reflector usage.
For details about the configurations of these features, see "BGP Configuration" in the HUAWEI
NetEngine5000E Core Router Configuration Guide - IP Routing.
5.3 Configuring an MBGP Peer

Valid routing information can be provided for the Reverse Path Forwarding (RPF) check only
after an MBGP connection is enabled in the multicast address family view.
The RPF check is performed on multicast packets based on the following routes:
l Multicast static routes
l Unicast routes
l MBGP routes
Valid routing information can be provided for the RPF check after an MBGP connection is
enabled in the multicast address family view.

Before configuring basic MBGP functions, complete the following task:
l Configuring basic multicast functions
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number
The BGP view is displayed.

Step 3 Run:
peer ip-address as-number as-number
The IP address and AS number of a remote peer are specified.

peer { ipv4-address | group-name } connect-interface interface-type interface-
number [ ipv4-source-address ]
The local interface and the source address used to set up a BGP connection are specified.
If the BGP connection is set up through a Loopback interface or a sub-interface, the command
is required.
peer { ip-address | group-name } ebgp-max-hop [ hop-count ]
The maximum number of hops of an EBGP connection is set.

The command is valid only for EBGP peers.
If the EBGP connection is set up through a Loopback interface, the command is required.
Step 6 Run:
ipv4-family multicast
The BGP-IPv4 multicast address family view is displayed.

Step 7 Run:
peer { peer-address | group-name } enable
MBGP is enabled for a BGP peer or peer group, which then becomes an MBGP peer or peer
group.
l group-name specifies the name of a BGP peer group.
l peer-address specifies the IP address of a remote BGP peer.
Step 8 Run:
commit
----End


After the configuration is completed, you can check if the configuration has taken effect.
Run the display bgp multicast peer [ peer-address ] [verbose ] command to check information
about MBGP peers.
<HUAWEI> display bgp multicast peer
Local AS number : 1
10.2.1.2 4 2 36 37 0 00:15:35 Established 24
5.4 Configuring MBGP to Import Local Routes

MBGP can import routes from other protocols. When routes are imported from dynamic routing
protocols, the process IDs of the routing protocols must be specified.
MBGP cannot discover routes by itself. Instead, it imports routes discovered by other protocols
such as an IGP or static routes into the MBGP routing table.
Routes imported into the MBGP table can be:
l Routes statically imported by using the network command
l Routes imported by using the import-route command
At least one type of routes need to be imported into the MBGP routing table as needed in a
particular usage scenario.
Before configuring MBGP to import routes, complete the following task:
l Configuring an MBGP peer
Do as follows on the routers that are configured as MBGP peers:
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:

Step 4 Run:
network ip-address [ mask-length | mask ] [ route-policy route-policy-name ]

MBGP is configured to import routes from the local routing table into the MBGP routing table
and then advertise the MBGP routes in the local network.
l ip-address [ mask-length | mask ] specifies the IP address, mask length, or mask information
of the imported routes.
l route-policy route-policy-name specifies a routing policy to control which routes can be
imported.
The destination address and mask length specified in the network command must be the same
as those of the entry in the local IP routing table. Otherwise, the specified routes will not be
imported.
Step 5 Run:
import-route protocol [ process-id ] [ med med-value | route-policy route-policy-
name ] *
IGP routes are imported into MBGP.
l protocol [ process-id ] specifies a routing protocol and the process ID of the routing protocol
from which routes are imported. The routing protocol is specified by direct, static, rip,
isis, or ospf. A process ID must be specified to import routes from IS-IS, OSPF, or RIP.
l med med-value specifies the MED value assigned to imported routes.
l route-policy route-policy-name specifies a route filtering policy. Only the routes that pass
filtering can be imported into the MBGP routing table.

default-route imported
Default routes are imported into the MBGP routing table.
By default, default routes are not imported into the MBGP routing table.
To import default routes, run the import-route command in conjunction with the default-route
imported command. If only the import-route command is used, default routes will not be
imported. In addition, the default-route imported command is used to import only the default
routes that exist in the local routing table.
Step 7 Run:
commit
----End

After the configuration is completed, you can check if the configuration has taken effect.
l Run the display bgp multicast network command to check routing information advertised
by MBGP.
l Run the display bgp multicast routing-table [ ip-address [ mask-length [ longer-
prefixes ] | mask [ longer-prefixes ] ] ] command to check the MBGP routing table.
# Run the display bgp multicast network command. You can view routing information
advertised by MBGP. For example:
<HUAWEI> display bgp multicast network

BGP Local Router ID is 2.2.2.9

Local AS Number is 100(Multicast)
Network Mask Route-policy
10.1.1.1 255.255.255.0
10.2.2.2 255.255.255.0
5.5 Controlling MBGP Route Advertisement

MBGP can filter or apply routing policies to the routes to be advertised to a peer or peer group.
MBGP advertises routes to peers based on the network plan for exchange of routing information
between devices. MBGP can filter or apply routing policies to the routes to be advertised to a
peer or peer group.
Before controlling MBGP route advertisement, complete the following task:
Choose certain configuration tasks from the following (except "Checking the Configuration")
as needed in a particular usage scenario.
5.5.1 Summarizing Local MBGP Routes

Configuring route summarization can reduce the size of a routing table on a peer. MBGP supports
automatic and manual route summarization.
Context
On a large-scale MBGP network, configuring route summarization can reduce the number of
advertised route prefixes and improve MBGP stability.
The following describes how to configure automatic or manual route summarization.
Procedure
l Configure automatic route summarization.
1. Run:
system-view

2. Run:
bgp as-number

3. Run:


4. Run:
summary automatic
Subnet routes are summarized based on natural network segment masks.

This command summarizes the routes imported into the MBGP routing table. The
routes may be direct routes, static routes, RIP routes, OSPF routes, or IS-IS routes.
Note that this command is invalid for the routes imported by using the network
command.
5. Run:
commit

l Configure manual route summarization.
1. Run:
system-view

2. Run:
bgp as-number

3. Run:

4. Run one of the following commands to configure route summarization as needed.
To advertise all summarized routes and specific routes, run:
aggregate ipv4-address { mask | mask-length }
To advertise only summarized routes, run:

aggregate ipv4-address { mask | mask-length } detail-suppressed
To advertise some of the specific routes, run:

aggregate ipv4-address { mask | mask-length } suppress-policy route-
policy-name3
Using the peer route-policy command can also advertise some of the specific
routes.
To generate the summarized route used for loop detection, run:
aggregate ipv4-address { mask | mask-length } as-set
To configure the attributes of summarized routes, run:

aggregate ipv4-address { mask | mask-length } attribute-policy route-
policy-name1
Using the peer route-policy command can also configure the attributes of
summarized routes.
If as-set is configured in the aggregate command, the AS_Path attribute
configured in the apply as-path command does not take effect.
To generate summarized routes based on some of the specific routes, run:
aggregate ipv4-address { mask | mask-length } origin-policy route-
policy-name2
Only the routes that exist in the local MBGP routing table can be manually
summarized. For example, if the route 10.1.1.1/24 is not in the MBGP routing table,

MBGP will not advertise the route summarized by using the aggregate 10.1.1.1 16
command.
5. Run:
commit
----End
5.5.2 Configuring MBGP to Advertise Default Routes to Peers

A device sends a default route with the local address as the next hop address to the specified
peer for load balancing purpose, regardless of whether there are default routes in the local routing
table. This greatly reduces the number of routes on the network.
Context
Default routes can be used in the networks with the following characteristics:
l There are multiple EBGP peers, and each peer can receive full Internet routes.
l There are multiple Route Reflectors (RRs), and each RR can receive full Internet routes.
When load balancing is not performed on the network, an MBGP peer receives at most one copy
of active full Internet routes. After load balancing is performed on the network, the number of
active routes received by the MBGP peer doubles, which causes the number of routes on the
network to sharply increase. In this case, you can configure the local device to advertise only
default routes to its MBGP peer and use default routes for load balancing, which can greatly
reduce the number of routes on the network.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
Step 4 Run:
peer { group-name | peer-address } default-route-advertise [ route-policy route-
policy-name ]
Default routes are advertised to an MBGP peer or peer group.
l group-name specifies the name of an MBGP peer group.

l peer-address specifies the IP address of a remote MBGP peer.
l route-policy route-policy-name specifies a routing policy to control which routes are
advertised.

Step 5 Run:
commit
----End
5.5.3 Configuring MBGP to Advertise the Community Attribute

The community and extended community attributes are used to simplify routing policy
management.
Context
The community attribute is transmitted between MBGP peers, and its transmission is not
restricted within ASs. With the community attribute, a group of routes can share the same routing
policy. Before sending a route with the community attribute to peers, MBGP can change the
original community attribute carried by the route.
Do as follows on the router that is configured as an MBGP peer:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
Step 4 Run one of the following commands as needed.

l To advertise the community attribute to an MBGP peer or peer group, run:
peer { group-name | peer-address } advertise-community
By default, the community attribute is not advertised to MBGP peers or peer groups.
group-name specifies the name of an MBGP peer group.
peer-address specifies the IP address of a remote MBGP peer.
l To advertise the extended community attribute to an MBGP peer or peer group, run:
peer { group-name | peer-address } advertise-ext-community
By default, the extended community attribute is not advertised to MBGP peers or peer groups.
group-name specifies the name of an MBGP peer group.
peer-address specifies the IP address of a remote MBGP peer.
Step 5 Run:
commit

----End

After MBGP route advertisement is configured, you can view MBGP routing information.
Prerequisite
The configurations of the policy governing MBGP route advertisement are complete.
Procedure
l Run the display bgp multicast routing-table community [ aa:nn ] & <0-13> [ no-
advertise | no-export | no-export-subconfed ] * [ whole-match ] command to check the
routes carrying the specified MBGP community attribute in the routing table.
l Run the display bgp multicast routing-table community-filter { { community-filter-
name | basic-community-filter-number } [ whole-match ] | advanced-community-filter-
number } command to check the routes that match the MBGP community filter.
l Run the display bgp multicast network command to check routing information advertised
by MBGP.
prefixes ] | mask [ longer-prefixes ] ] ] command to check the MBGP routing table.
l Run the display bgp multicast routing-table cidr command to check Classless
InterDomain Routing (CIDR) information.
l Run the display bgp multicast routing-table statistics command to check statistics about
the entries in the MBGP routing table.
----End
Example
# Run the display bgp multicast network command, and you can view routing information
advertised by MBGP. For example:
10.1.1.1 255.255.255.0
10.2.2.2 255.255.255.0
5.6 Controlling MBGP Route Selection

The policy governing MBGP route selection can be changed by configuring MBGP route
attributes.
MBGP has many route attributes. These attributes are used to define the routing policy and
describe the MBGP route prefix. Configuring these attributes can change the policy governing
MBGP route selection.

Before controlling MBGP route selection, complete the following task:
as needed in a particular usage scenario.
5.6.1 Configuring Preferences for MBGP Routes

Setting the MBGP preference affects route selection among MBGP and other routing protocols.
Context
NOTE
This configuration is optional. By default, the default preferences of EBGP routes, IBGP routes, and local
routes are all 255.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
Step 4 Run:
preference { external-preference internal-preference local-preference | route-
policy route-policy-name }
MBGP preferences are set for internal, external, and local routes.
l external-preference specifies the preference for routes learned from EBGP peers.
l internal-preference specifies the preference for routes learned from IBGP peers.
l local-preference specifies the preference for locally originated routes.
l route-policy route-policy-name specifies a routing policy. The set MBGP preference will
be applied to the routes that match the policy.
Step 5 Run:
commit

----End
5.6.2 Setting a Preferred Value for Routes Learned from an MBGP

Peer
After preferred values are set for MBGP routes, the route with the greatest value is preferred
when multiple routes to the same destination exist in the MBGP routing table.
Context
NOTE
This configuration is optional. By default, the preferred value of an MBGP route is 0.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:

Step 4 Run:
peer { group-name |peer-address } preferred-value preference-value
A preferred value is set for the routes learned from an MBGP peer or peer group.
A route with the greatest preferred value will be selected as the optimal route to a specified
network if there are multiple routes to that network.
Step 5 Run:
commit
----End
5.6.3 Setting the Local_Pref Attribute for MBGP Routes

The Local_Pref attribute has the same function as the preferred value of a route. If both of them
are configured for an MBGP route, the preferred value takes precedence over the Local_Pref
attribute.

Context
The Local_Pref attribute is used to determine the optimal route for the traffic that leaves an AS.
If an MBGP device obtains multiple routes from different IBGP peers and these routes have
different next hops to the same destination, the MBGP device will select the route with the
greatest Local_Pref value.
NOTE
This configuration is optional. By default, the Local-Pref attribute value of an MBGP route is 100.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:

Step 4 Run:
default local-preference preference-value
The Local_Pref attribute is set for the local device.

Step 5 Run:
commit
----End
5.6.4 Setting the MED Attribute for MBGP Routes

The MED attribute is equal to the metric used in IGP. After the MED attribute is set for routes,
an EBGP peer can select a route with the smallest MED value for the traffic that enters an AS.
Context
The MED serves as the metric used by an IGP. It is used to determine the optimal route when
traffic enters an AS. When a MBGP router obtains multiple routes to the same destination address
but with different next hops through EBGP peers, the route with the smallest MED value is
selected as the optimal route.
Procedure
l Set the default MED value on the local device.

1. Run:
system-view

2. Run:
bgp as-number

3. Run:

4. Run:
default med med
The default MED value is set.

5. Run:
commit

l Compare the MED values of the routes from different ASs.
1. Run:
system-view

2. Run:
bgp as-number

3. Run:

4. Run:
compare-different-as-med
The MED values of routes from different ASs are compared.
By default, an MBGP router compares only the MED values of the routes from
different peers in the same AS. This command enables MBGP to compare the MED
values of routes from different ASs.
5. Run:
commit

l Configure the method used by MBGP when there is no MED attribute in the route attributes.
1. Run:
system-view

2. Run:
bgp as-number


3. Run:

4. Run:
bestroute med-none-as-maximum
The maximum MED value is used for a route if the route has no MED value.
If this command is not run, MBGP uses 0 as the MED value for a route if the route
has no MED value.
5. Run:
commit
----End
5.6.5 Setting the Next_Hop Attribute

MBGP route selection can be flexibly controlled by setting the Next_Hop attribute.
Context
Different from that in IGP, the next-hop address in MBGP may not be the IP address of a peer
router.
Procedure
l Configure a device to change the next-hop address when it advertises a route to an IBGP
peer.
Do as follows on the IBGP router:
1. Run:
system-view

2. Run:
bgp as-number

3. Run:

4. Run:
peer { peer-address | group-name } next-hop-local
The local address is configured as the next-hop address for route advertisement.
In certain networks, to ensure that an IBGP peer can find the correct next hop, you
can configure the local device to change the next-hop address of a route to be its own
address when the local device advertises the route to its IBGP peer.

By default, a device does not change the next-hop address when advertising a route
to its IBGP peer.
NOTE
If MBGP load balancing is configured, the local router changes the next-hop address to be its
own address when advertising routes to IBGP peer groups, regardless of whether the peer
{ group-name | peer-address } next-hop-local command is used.
5. Run:
commit

----End
5.6.6 Setting the AS_Path Attribute

The AS_Path attribute is used to prevent routing loops and control route selection.
Procedure
l Configure MBGP not to compare the AS_Path attribute in the route selection process.
1. Run:
system-view

2. Run:
bgp as-number

3. Run:

4. Run:
bestroute as-path-ignore
MBGP is configured to ignore the AS_Path attribute in route selection.

l Configure the AS_Path attribute to carry only the public AS number.
1. Run:
system-view

2. Run:
bgp as-number

3. Run:

4. Run:
peer { ipv4-address | group-name } public-as-only
The AS_Path attribute is configured to carry only the public AS number.

The number of an AS ranges from 1 to 4294967295. A public AS number ranges from

1 to 64511, and from 65536 (1.0 in the x.y format) to 4294967295 (65535.65535 in
the x.y format); a private AS number ranges from 64512 to 65534; the AS number
65535 is reserved for particular use.
Public AS numbers can be used on the Internet. They are assigned and managed by
the Internet Assigned Number Authority (IANA). Private AS numbers cannot be
advertised to the Internet. They are used only within ASs.
Usually, the routes advertised among MBGP peers carry the AS number information.
The AS number may be a public AS number or a private AS number. If the private
AS number does not need to be advertised, this command can be run to allow the
AS_Path attribute to carry only the public AS number.
NOTE
The peer public-as-only command is valid only on EBGP peers.

5. Run:
commit

----End

After MBGP route attributes are configured, you can view information about the route attributes.
Prerequisite
The configurations of the policy governing the MBGP route selection are complete.
Procedure
prefixes ] | mask [ longer-prefixes ] ] ] command to check routes in the MBGP routing
table.
l Run the display bgp multicast routing-table statistics command to check statistics about
the entries in the MBGP routing table.
----End
Example
Run the display bgp multicast routing-table command. you can view information about MBGP
route. For example:
<HUAWEI> display bgp multicast routing-table 10.3.1.0
Paths : 1 available, 1 best, 1 select
BGP routing table entry information of 10.3.1.0/30:
From: 10.2.1.2 (5.5.5.5)
Route Duration: 0d00h00m23s
Relay IP Nexthop: 10.2.1.2
Relay IP Out-interface: Ethernet3/0/0
Original nexthop: 10.2.1.2
Qos information : 0x2d
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, intern

al, best, select, pre 255

Not advertised to any peer yet
5.7 Configuring MBGP Routing Policies

MBGP routing policies can be configured to flexibly control the sending and receiving of routes.
Routing policies can be used to set or re-set MBGP route attributes by using some predefined
conditions, which provides a flexible and effective method to control MBGP route selection.
The sending and receiving of routes can be flexibly controlled by applying MBGP routing
policies.
Before configuring MBGP routing policies, complete the following task:
l Configuring MBGP Peers
as needed in the applicable environment.
5.7.1 Configuring a Route-policy

A route-policy is used to filter routes.
Context
A route-policy is used to match routes or route attributes, and to change route attributes when
the matching rules are met.
Do as follows on the router that is configured as an MBGP peer.
NOTE
This configuration is optional. By default, no route-policy is configured for route filtering.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:

Step 4 Run:
peer { group-name | peer-address } route-policy route-policy-name { import |
export }
A route-policy is configured to filter MBGP routes. The routes exchanged between the device
and its remote MBGP peer can thus be controlled.
l group-name specifies an MBGP peer group.
l peer-address specifies the IP address of the remote MBGP peer.
l route-policy-name specifies the name of a route-policy.
l import is used to filter routes received from a specified remote MBGP peer. Only the routes
that pass the filtering will be accepted.
l export is used to filter routes sent by a specified remote MBGP peer. Only the routes that
pass the filtering will be sent out.
Step 5 Run:
commit
----End
5.7.2 Configuring a Policy for Receiving MBGP Routes

MBGP filters received routes by using a policy. Only the routes that match the policy can be
installed into a routing table.
Context
MBGP can apply a routing policy to all received routes or only routes received from a certain
peer or peer group.
MBGP provides peer-specific route control to limit the number of routes sent from a peer or
peer group. If a device is under malicious attacks or some network configurations are incorrect,
the device will receive a large number of routes from its MBGP peers, consuming lots of device
resources. Therefore, the administrator must limit resources consumed by MBGP devices based
on device capacities.
Procedure
l Configure MBGP to filter all received routes.
1. Run:
system-view

2. Run:
bgp as-number

3. Run:

4. Run:
filter-policy { basic-acl-number | acl-name acl-name | ip-prefix ip-prefix-
name } import
A policy is configured to filter all received MBGP routes. Routes exchanged between
the device and any of its MBGP peers can thus be controlled.
basic-acl-number or acl-name acl-name specifies an ACL.
ip-prefix-name specifies an IP prefix list.
import is used to filter routes received from any MBGP peers. Only the routes that
pass the filtering are accepted.
5. Run:
commit

l Configure MBGP to filter the routes received from a certain peer or peer group.
1. Run:
system-view

2. Run:
bgp as-number

3. Run:

4. Run the following commands as needed to configure MBGP to use different filters to
filter routes received from peers:
To use an ACL for route filtering, run:
peer { peer-address | group-name } filter-policy { basic-acl-number |
acl-name acl-name } import
To use the AS_Path filter for route filtering, run:

peer { peer-address | group-name } as-path-filter filter-number import
To use a prefix list for route filtering, run:

peer { peer-address | group-name } ip-prefix ip-prefix-name import
A peer group and its members can use different inbound policies when receiving
routes. This means that each member in a peer group can select its own policy to filter
received routes.
5. Run:
commit

l Limit the number of routes received from peers.
1. Run:
system-view

2. Run:
bgp as-number


3. Run:
ipv4-family multicast multicast

4. Run:
peer { group-name | peer-address } route-limit maximum-limit
[ percentage ] [ alert-only | idle-forever | idle-timeout times ]
The number of routes that can be received from a peer or peer group is set.
The command provides peer-specific control. You can set specific parameters as
needed to control the MBGP device's behaviors after the number of the routes received
from a peer exceeds the limit.
If alert-only is set, the device does not interrupt the peer relationship but does not
receive any follow-up routes after the number of received routes exceeds the limit.
In addition, the device generates an alarm and then records it in the log file.
If idle-forever is set, the device interrupts the peer relationship, and does not
attempt to establish a connection. In addition, the device generates an alarm and
then records it in the log file. Then, run the display bgp multicast peer
[ verbose ] command, and you can see that the peer relationship is in the Idle state.
To restore the MBGP connection, run the reset bgp command.
If idle-timeout is set, the device interrupts the peer relationship, and attempts to
re-establish the connection after the corresponding timer expires. In addition, it
generates an alarm and then records it in the log file. Then, run the display bgp
multicast peer [ verbose ] command, and you can see that the peer relationship
is in the Idle state. To restore the BGP connection before the timer expires, run the
reset bgp command.
If none of the preceding parameters is set, the device interrupts the peer
relationship, and attempts to establish a connection after 30s. In addition, the device
generates an alarm and then records it in the log file.
NOTE
If the number of routes received by the router exceeds the upper threshold and the peer route-
limit command is used for the first time, the router and its peer re-establish the peer relationship,
regardless of whether alert-only is set.
5. Run:
commit
----End
5.7.3 Configuring a Policy for Advertising MBGP Routes

After MBGP filters the imported routes, only the routes that pass the filtering are added to the
local MBGP routing table and advertised to MBGP peers.
Context
MBGP can apply a routing policy to all the routes to be advertised.

Procedure
l Configure MBGP to filter all the routes to be advertised.
1. Run:
system-view

2. Run:
bgp as-number

3. Run:

4. Run:
filter-policy { basic-acl-number | acl-name acl-name | ip-prefix ip-prefix-
name } export [ protocol [ process-id ] ]
The routes to be advertised are filtered.
basic-acl-number or acl-name acl-name specifies an ACL.

ip-prefix-name specifies the name of an IP-prefix list.
export [ protocol [ process-id ] ] is used to filter routes to be advertised to any
MBGP peers. After the filter-policy export command is used, MBGP filters the
routes to be imported by using the import-route command before importing them.
Only the routes that pass the filtering are added to the MBGP routing table and are
advertised by MBGP.
5. Run:
commit

l Configure MBGP to filter routes to be advertised to a specified peer or peer group.
1. Run:
system-view

2. Run:
bgp as-number

3. Run:

4. Run the following commands as needed to configure MBGP to use different filters to
filter routes to be advertised to a peer:
To use an ACL for route filtering, run:
peer { peer-address | group-name } filter-policy { basic-acl-number |
acl-name acl-name } export
To use the AS_Path filter for route filtering, run:

peer { peer-address | group-name } as-path-filter filter-number export

To use a prefix list for route filtering, run:

peer { peer-address | group-name } ip-prefix ip-prefix-name export
A peer group and its members can use different export policies when advertising
routes. This means that each member in a peer group can select its own policy when
advertising routes.
5. Run:
commit
----End
5.7.4 Configuring MBGP Soft Resetting

MBGP soft resetting allows the system to refresh an MBGP routing table dynamically without
tearing down any MBGP connection if routing policies are changed.
Procedure
l Enable the route-refresh capability.
Do as follows on an MBGP device:
1. Run:
system-view

2. Run:
bgp as-number

3. Run:
peer { ipv4-address | ipv6-address | group-name } capability-advertise {
route-refresh | 4-byte-as }
The Route-Refresh capability is enabled.
Assume that all MBGP routers are enabled with the route-refresh capability, if an
MBGP routing policy changes, the local router sends route-refresh messages to its
peers. After receiving the messages, these peers resend their routing information to
the local router. Based on the received routing information, the local router can refresh
its MBGP routing table dynamically and apply the new policy, without tearing down
any MBGP connections.
By default, the route-refresh capability is enabled.

4. Run:
commit

l Configure an MBGP device to store all the routing updates received from its peers.
1. Run:
system-view


2. Run:
bgp as-number

3. Run:

4. Run:
peer { ipv4-address | ipv6-address | group-name } keep-all-routes
The device is configured to store all routing updates received from its peers.
After this command is used, all route updates sent by a specified peer are stored,
regardless of whether a filtering policy is used. When the local routing policy changes,
the route updates can be used to regenerate MBGP routes.
5. Run:
commit

l Softly reset an MBGP connection.
1. Run:
refresh bgp ipv6 { all | ipv4-address | ipv6-address | group group-name |
external | internal } { export | import }
An MBGP connection is softly reset.
The MBGP connection must be softly reset in the user view.
----End

After the policies for route exchanges between MBGP peers are configured, you can view MBGP
routes.
Prerequisite
The configurations of policies for route exchanges between MBGP peers are complete.
Procedure
l Run the display bgp multicast routing-table different-origin-as command to check the
routes that have the same destination address but different original AS numbers.
l Run the display bgp multicast routing-table regular-expression [ as-regular-
expression ] command to check the routes that match the AS regular expression.
l Run the display bgp multicast paths [ as-regular-expression ] command to check the
AS_Path attributes of routes.
l Run the display bgp multicast routing-table as-path-filter as-path-filter-number
command to check the routes that match a specified AS_Path filter.

l Run the display bgp multicast routing-table community-filter { { community-filter-

name | basic-community-filter-number } [ whole-match ] | advanced-community-filter-
number } command to check the routes that match an MBGP community filter.
l Run the display bgp multicast routing-table peer peer-address { advertised-routes |
received-routes } [ statistics ] command to check the routes sent to or received from a
specified MBGP peer.
l Run the display bgp multicast network command to check the routes advertised by
MBGP.
----End
Example
Run the display bgp multicast network command. You can view the routes imported by using
the network command.
10.1.1.1 255.255.255.0
10.2.2.2 255.255.255.0
5.8 Configuring MBGP Load Balancing

Configuring MBGP load balancing better utilizes network resources.
MBGP load balancing can be performed among routes that have the same AS_Path attribute and
conform to the first nine rules in "MBGP Route Selection Rules".
Before configuring MBGP load balancing, complete the following task:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:

Step 4 Run:
maximum load-balancing number
The number of routes for MBGP load balancing is set.

By default, the number of routes for MBGP load balancing is 1.
Step 5 Run:
commit
----End

After the configuration is complete, you can check whether the configuration has taken effect.
l Run the display bgp multicast routing-table ipv6-address prefix-length command to
check routes in the MBGP routing table.
Run the display bgp multicast routing-table command. You can view routes for MBGP load
balancing. For example:
<HUAWEI>display bgp multicast routing-table 111::111

Paths : 2 available, 1 best, 2 select
From: 200.1.1.2 (2.2.2.2)
Direct Out-interface: Pos1/0/0
Qos information : 0x0
AS-path 200 300, origin igp, pref-val 0, valid, external, best, select, pre 255
Advertised to such 2 peers
200.1.1.2
200.1.2.2

From: 200.1.2.2 (3.3.3.3)
Direct Out-interface: Pos2/0/0
Qos information : 0x0
AS-path 200 300, origin igp, pref-val 0, valid, external, select, pre 255, not
selected for router ID
Not advertised to any peers yet
5.9 Configuring MBGP Route Dampening

Configuring MBGP route dampening suppresses instable MBGP routes.
MBGP route dampening is designed to suppress instable routes. After being configured with
MBGP route dampening, an MBGP device does not add any instable routes to its MBGP routing
table or advertise them to its MBGP peers.
A primary cause of route instability is route flapping. A route is considered to be flapping when
it repeatedly appears and then disappears in the routing table. MBGP is applied to complex

networks where routes change frequently. Frequent route flapping consumes lots of bandwidth
and CPU resources and even seriously affects network operations. To prevent the impact of
frequent route flapping, MBGP uses route dampening to suppress instable routes.
Specified-requirement route dampening is a type of route dampening that is used to differentiate

routes based on routing policies. This allows MBGP to use different route dampening parameters
to suppress instable routes. Different route dampening parameters can also be configured for
different nodes in the same route-policy. When route flapping occurs, MBGP can use specific
route dampening parameters to suppress the routes that match the route-policy. For example, on
a network, a long dampening period of time can be set for routes with a long mask, and a short
dampening period of time is set for routes with a short mask (such as an 8-bit mask).
Before configuring MBGP route dampening, complete the following task:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
Step 4 Run:
dampening [ half-life-reach reuse suppress ceiling | route-policy route-policy-
name ] *
MBGP route dampening parameters are set.
NOTE
The dampening command is valid only for EBGP routes.
The value of suppress must be greater than that of reuse and smaller than that of ceiling.
If routes are differentiated based on policies and the dampening command is run to reference
a route-policy, MBGP allow you to use different route dampening parameters to suppress
different routes.
Step 5 Run:
commit
----End


l Run the display bgp multicast routing-table dampened command to check dampened
MBGP routes.
l Run the display bgp multicast routing-table dampening parameter command to check
configured MBGP route dampening parameters.
l Run the display bgp multicast routing-table flap-info [ ip-address [ mask [ longer-
match ] | mask-length [ longer-match ] ] | as-path-filter as-path-filter-number | regular-
expression as-regular-expression ] command to check MBGP route flapping statistics.
Run the display bgp multicast routing-table dampened command. You can view dampened
routes. For example:
<HUAWEI> display bgp multicast routing-table dampened
BGP local router ID is 12.12.12.9

Network From Reuse Path/Ogn
d 100.1.0.0/16 10.2.1.1 00:45:05 1?
5.10 Configuring MBGP RRs

MBGP RRs resolve the problem of full-mesh connections between multiple IBGP peers, which
reduces network costs.
Full-mesh connections need to be established between IBGP peers in an AS to ensure the
connectivity between the IBGP peers. When there are many IBGP peers, it is costly to establish
a fully-meshed network. An RR can be used to solve the problem.
Before configuring MBGP RRs, complete the following task:
CAUTION
An RR takes effect only for IBGP peers. Before configuring an MBGP RR, establish an IBGP
peer relationship between the RR and each of its clients.
This configuration is optional. By default, no RR is configured.
Do as follows on the router to be configured as an MBGP RR:

Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:

Step 4 Run:
peer { group-name | peer-address } reflect-client
The device is configured as an RR and its peer or peer group is configured as a client.
reflector cluster-id { decimal-value | ipv4-address }
A cluster ID is configured for the RR.

By default, an RR uses its router ID as the cluster ID.
l decimal-value specifies a cluster ID in the decimal format.
l ipv4-address specifies a cluster ID in the format of an IPv4 address.
Step 6 Run:
commit
----End

prefixes ] | mask [ longer-prefixes ] ] ] command to check routes in the MBGP routing
table.
Run the display bgp multicast routing-table command. You can view routes in the MBGP
routing table.
<HUAWEI> display bgp multicast routing-table
BGP local router ID is 13.13.13.9


Network NextHop MED LocPrf PrefVal Path/Ogn

*> 3.3.3.3/32 0.0.0.0 0 0 ?

*> 4.4.4.4/32 10.2.1.2 0 2?
*> 6.1.1.0/24 10.2.1.2 0 2?
*> 7.1.1.0/24 0.0.0.0 0 0 ?
*> 7.1.1.1/32 0.0.0.0 0 0 ?
*> 10.1.2.0/24 10.2.1.2 0 2?
*> 10.1.13.0/24 0.0.0.0 0 0 ?
*> 10.1.13.2/32 0.0.0.0 0 0 ?
*> 10.2.1.0/24 0.0.0.0 0 0 ?
*> 10.2.1.0/24 10.2.1.2 0 0 2?
*> 10.2.1.1/32 0.0.0.0 0 0 ?
*> 10.2.13.0/24 0.0.0.0 0 0 ?
*> 10.2.13.1/32 0.0.0.0 0 0 ?
*> 10.2.13.2/32 0.0.0.0 0 0 ?
5.11 Maintaining MBGP

Maintaining MBGP involves resetting MBGP connections, clearing MBGP statistics, and
debugging MBGP.
5.11.1 Resetting MBGP Connections

Resetting MBGP connections interrupts peer relationships.
Context
CAUTION
MBGP peer relationships between routers are interrupted if you reset MBGP connections by
using the reset bgp multicast command. Exercise caution when resetting MBGP connections.
Procedure
l Run the reset bgp multicast peer-address command in the user view to reset the MBGP
connection between specified peers.
l Run the reset bgp multicast all command in the user view to reset all MBGP connections.
l Run the reset bgp multicast group group-name command in the user view to reset the
MBGP connections between all peers in a peer group.
l Run the reset bgp multicast external command in the user view to reset external
connections.
l Run the reset bgp multicast internal command in the user view to reset internal
connections.
----End
5.11.2 Clearing MBGP Statistics

Clearing MBGP statistics involves clearing MBGP route flapping statistics and route dampening
statistics.

Context
CAUTION
MBGP statistics cannot be restored after they are cleared. Therefore, exercise caution when
using reset commands.
Procedure
l Run the reset bgp multicast dampening [ ip-address [ mask | mask-length ] ] command
in the user view to clear MBGP route dampening statistics.
l Run the reset bgp multicast flap-info [ ip-address [ mask-length | mask ] | as-path-
filter as-path-list-number | regrexp regrexp ] command in the user view to clear MBGP
route flapping statistics.
----End

This chapter provides an MBGP configuration example. In the configuration example, the
networking requirements, network diagram, precautions, configuration roadmap, and
configuration procedures are provided.
5.12.1 Example for Configuring Basic MBGP Functions

Before building an MBGP network, you need to configure basic MBGP functions.
As shown in Figure 5-1, the receiver receives VoD information in multicast mode. The receiver
and the source reside in different ASs. An MBGP peer relationship is established between
router A and router B to transmit multicast routing information.

Figure 5-1 Networking diagram for configuring basic MBGP functions
AS100 AS200
RouterD
Loopback0
POS2/0/0
POS1/0/0
Source RouterA POS2/0/0

RouterB
GE2/0/0 POS1/0/0
POS1/0/0 POS3/0/0
Loopback0 Loopback0
POS3/0/0 POS1/0/0
RouterC Loopback0
GE2/0/0
Receiver
MBGP peers
Router A POS 1/0/0 192.1.1.1/24 Router C POS 1/0/0 195.1.1.1/24
GE 2/0/0 10.10.10.1/24 GE 2/0/0 22.22.22.1/24
Loopback 0 1.1.1.1/32 POS 3/0/0 193.1.1.1/24
Router B POS 1/0/0 192.1.1.2/24 Loopback 0 3.3.3.3/32
POS 2/0/0 194.1.1.2/24 Router D POS 1/0/0 195.1.1.2/24
POS 3/0/0 193.1.1.2/24 POS 2/0/0 194.1.1.1/24
Loopback 0 2.2.2.2/32 Loopback 0 4.4.4.4/32
1. Configure an IP address for each interface on the routers to make unicast routes reachable
in each AS.
2. Establish MBGP peer relationships to build inter-AS multicast routes.
3. Configure MBGP to import routes.
4. Enable multicast on each router.

5. Configure basic PIM-SM functions in each AS, and enable IGMP on the interface
connected to user hosts.
6. Configure BSR boundaries on the interfaces directly connecting router A and router B.
7. Establish MSDP peer relationships to transmit inter-AS multicast source information.
8. Verify the configuration.
Data Preparation
l AS number of Router A: 100
l AS numbers of Router B, Router C, and Router D: 200
l Multicast group address: 225.1.1.1; multicast source address: 10.10.10.10/24
Procedure
Step 1 Configure an IP address for each interfaces on the routers and configure OSPF in each AS.
# Configure an IP address and mask for each interface on the routers and configure OSPF in
each AS. Ensure that Router B, Router C, Router D, and receiver in AS 200 can
intercommunicate at the network layer, and learn the routes to each other's loopback interface.
Ensure that the routers implement dynamic routing updates by running the unicast routing
protocol. Configure OSPF process 1 on all the devices. The configuration details are not provided
here.
Step 2 Configure BGP, enable MBGP, and configure MBGP peer relationships.
# On Router A, enable BGP and configure the MBGP peer relationship.
[~RouterA] bgp 100
[~RouterA-bgp] peer 192.1.1.2 as-number 200
[~RouterA-bgp] ipv4-family multicast
[~RouterA-bgp-af-multicast] peer 192.1.1.2 enable
[~RouterA-bgp-af-multicast] commit
[~RouterA-bgp-af-multicast] quit
[~RouterA-bgp] quit
# On Router B, enable BGP and configure the MBGP peer relationship.

[~RouterB] bgp 200
[~RouterB-bgp] ipv4-family multicast
[~RouterB-bgp-af-multicast] peer 192.1.1.1 enable
[~RouterB-bgp-af-multicast] commit
[~RouterB-bgp-af-multicast] quit
[~RouterB-bgp] quit
# On Router C, enable BGP and configure the MBGP peer relationship.

[~RouterC] bgp 200
[~RouterC-bgp] ipv4-family multicast
[~RouterC-bgp-af-multicast] peer 193.1.1.2 enable
[~RouterC-bgp-af-multicast] peer 195.1.1.2 enable
[~RouterC-bgp-af-multicast] commit
[~RouterC-bgp-af-multicast] quit

[~RouterC-bgp] quit
# On Router D, enable BGP and configure the MBGP peer relationship.

[~RouterD] bgp 200
[~RouterD-bgp] peer 194.1.1.2 as-number 200
[~RouterD-bgp] peer 195.1.1.1 as-number 200
[~RouterD-bgp] ipv4-family multicast
[~RouterD-bgp-af-multicast] peer 194.1.1.2 enable
[~RouterD-bgp-af-multicast] peer 195.1.1.1 enable
[~RouterD-bgp-af-multicast] commit
[~RouterD-bgp-af-multicast] quit
[~RouterD-bgp] quit
Step 3 Configure MBGP to import routes.

# On Router A, configure MBGP to import routes.
[~RouterA] bgp 100
[~RouterA-bgp] import-route direct
[~RouterA-bgp] ipv4-family multicast
[~RouterA-bgp-af-multicast] import-route direct
[~RouterA-bgp-af-multicast] commit
[~RouterA-bgp-af-multicast] quit
[~RouterA-bgp] quit
# On Router B, configure MBGP to import routes.

[~RouterB] bgp 200
[~RouterB-bgp] import-route direct
[~RouterB-bgp] import-route ospf 1
[~RouterB-bgp] ipv4-family multicast
[~RouterB-bgp-af-multicast] import-route direct
[~RouterB-bgp-af-multicast] import-route ospf 1
[~RouterB-bgp-af-multicast] commit
[~RouterB-bgp-af-multicast] quit
[~RouterB-bgp] quit
# On Router C, configure MBGP to import routes. The configuration on Router D is similar to

that on Router C, and is not provided here.
[~RouterC] bgp 200
[~RouterC-bgp] import-route direct
[~RouterC-bgp] ipv4-family multicast
[~RouterC-bgp-af-multicast] import-route direct
[~RouterC-bgp-af-multicast] import-route ospf 1
[~RouterC-bgp-af-multicast] commit
[~RouterC-bgp-af-multicast] quit
[~RouterC-bgp] quit
Step 4 Enable multicast on the routers and interfaces connecting the routers.
# Configure Router A.
[~RouterA] interface Pos1/0/0
[~RouterA] interface GigabitEthernet2/0/0
[~RouterA] commit
# Configure Router B.
[~RouterB] interface Pos1/0/0

[~RouterB] commit
# Configure Router C.
[~RouterC] interface Pos1/0/0
[~RouterC] GigabitEthernet2/0/0
[~RouterC] interface Pos3/0/0
[~RouterC] commit
# Configure Router D.
[~RouterD] interface Pos1/0/0
[~RouterD] interface Pos2/0/0
[~RouterD] commit
Step 5 Configure a BSR and an RP in each AS.
[~RouterA] interface loopback 0
[~RouterA-LoopBack0] ip address 1.1.1.1 255.255.255.255
[~RouterA-LoopBack0] pim sm
[~RouterA-LoopBack0] quit
[~RouterA] pim
[~RouterA-pim] c-bsr loopback 0
[~RouterA-pim] c-rp loopback 0
[~RouterA-pim] quit
[~RouterA] commit
[~RouterB] interface loopback 0
[~RouterB-LoopBack0] ip address 2.2.2.2 255.255.255.255
[~RouterB-LoopBack0] pim sm
[~RouterB-LoopBack0] quit
[~RouterB] pim
[~RouterB-pim] c-bsr loopback 0
[~RouterB-pim] c-rp loopback 0
[~RouterB] quit
[~RouterB] commit
Step 6 Configure BSR boundaries on the interfaces directly connecting Router A and Router B.
[~RouterA] interface Pos1/0/0
[~RouterA-Pos1/0/0] pim bsr-boundary


[~RouterB-Pos1/0/0] pim bsr-boundary
Step 7 Configure the MSDP peer relationship.

[~RouterA] msdp
[~RouterA-msdp] peer 192.1.1.2 connect-interface Pos 1/0/0
[~RouterA-msdp] commit
[~RouterA-msdp] quit
[~RouterB] msdp
[~RouterB-msdp] peer 192.1.1.1 connect-interface Pos 1/0/0
[~RouterB-msdp] commit
[~RouterB-msdp] quit

# Run the display bgp multicast peer command to check the MBGP peer relationships between
routers. For example, the MBGP peer relationship on Router A is displayed.
[~RouterA] display bgp multicast peer
192.1.1.2 4 200 82 75 0 00:30:29 Established 17
# Run the display msdp brief command to check the MSDP peer relationships between
routers. For example, the MSDP peer relationship on Router B is displayed.
[~RouterB] display msdp brief
1 1 0 0 0 0
192.1.1.1 Up 00:07:17 100 1 0
----End
Configuration Files
#
sysname RouterA
#
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.1.1.1 255.255.255.0
pim bsr-boundary
pim sm
#
undo shutdown
ip address 10.10.10.1 255.255.255.0
pim sm
#
interface loopback 0
ip address 1.1.1.1 255.255.255.255
pim sm

#
bgp 100
#
ipv4-family unicast
undo synchronization
import-route direct
#
import-route direct
#
pim
c-bsr loopback 0
c-rp loopback 0
#
msdp
peer 192.1.1.2 connect-interface Pos 1/0/0
#
return
#
sysname RouterB
#
#
interface pos 1/0/0
undo shutdown
link-protocol ppp
ip address 192.1.1.2 255.255.255.0
pim bsr-boundary
pim sm
#
interface pos 2/0/0
undo shutdown
link-protocol ppp
ip address 194.1.1.2 255.255.255.0
pim sm
#
interface pos 3/0/0
undo shutdown
link-protocol ppp
ip address 193.1.1.2 255.255.255.0
pim sm
#
ip address 2.2.2.2 255.255.255.255
pim sm
#
bgp 200
#
ipv4-family unicast
import-route direct
import-route ospf 1
#
import-route direct
import-route ospf 1


#
ospf 1
area 0.0.0.0
network 193.1.1.0 0.0.0.255
network 194.1.1.0 0.0.0.255
network 2.2.2.2 0.0.0.0
#
pim
c-bsr loopback 0
c-rp loopback 0
#
msdp
peer 192.1.1.1 connect-interface Pos 1/0/0
#
return
#
sysname RouterC
#
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 195.1.1.1 255.255.255.0
pim sm
#
undo shutdown
ip address 22.22.22.1 255.255.255.0
pim sm
igmp enable
#
interface pos 3/0/0
undo shutdown
link-protocol ppp
ip address 193.1.1.1 255.255.255.0
pim sm
#
ip address 3.3.3.3 255.255.255.255
pim sm
#
bgp 200
#
ipv4-family unicast
import-route direct
import-route ospf 1
#
import-route direct
import-route ospf 1
#
ospf 1
area 0.0.0.0
network 193.1.1.0 0.0.0.255
network 195.1.1.0 0.0.0.255
network 22.22.22.0 0.0.0.255
network 3.3.3.3 0.0.0.0

#
return

#
sysname RouterD
#
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 195.1.1.2 255.255.255.0
pim sm
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 194.1.1.1 255.255.255.0
pim sm
#
ip address 4.4.4.4 255.255.255.255
pim sm
#
bgp 200
#
ipv4-family unicast
import-route direct
import-route ospf 1
#
import-route direct
import-route ospf 1
#
ospf 1
area 0.0.0.0
network 194.1.1.0 0.0.0.255
network 195.1.1.0 0.0.0.255
network 4.4.4.4 0.0.0.0
#
return

Configuration Guide - IP Multicast 6 IP Multicast Routing Management
6 IP Multicast Routing Management
About This Chapter
The system synchronously maintains multiple multicast routing protocols, and controls multicast
routing and forwarding through the information exchang between the control plane and the
forwarding plane.
6.1 Introduction to IP Multicast Routing Management

Multicast routing and forwarding is implemented based multicast protocol routing tables and
the multicast forwarding table; multicast routing and forwarding control is implemented based
on multicast routing management.
6.2 IP Multicast Routing Management Features Supported by the NE5000E
The NE5000E supports multicast static routes and multicast load splitting.
6.3 Configuring RPF Routes
A multicast routing protocol creates multicast routing entries based on the RPF mechanism and
then establishes an MDT.
6.4 Adjusting the Minimum TTL Value for Multicast Forwarding
Multicast information of each multicast group in a network should be transmitted within a certain
range. Therefore, setting the minimum TTL value for multicast forwarding is necessary for
limiting the multicast data forwarding scope.
Examples for configuring multicast static routes, multicast load splitting, and multicast multi-
topology are provided.

6.1 Introduction to IP Multicast Routing Management

Multicast routing and forwarding is implemented based multicast protocol routing tables and
the multicast forwarding table; multicast routing and forwarding control is implemented based
on multicast routing management.
In multicast implementation on the NE5000E, multicast routing and forwarding involves the
following aspects:
l Each multicast routing protocol has its own routing table, such as a PIM routing table.
l Routing information of each multicast routing protocol is directly delivered to a multicast
forwarding table. The multicast forwarding table controls the forwarding of multicast data
packets.
A multicast routing protocol creates multicast routing entries based on the Reverse Path
Forwarding (RPF) mechanism. This ensures that multicast data can be transmitted along a correct
path. The system performs the RPF check based on the following types of routes:
l Unicast routes
The unicast routing table collects the shortest route to each destination.
l Multicast static routes
The multicast static routing table provides the information on the RPF route that is specified
through static configuration.
Multicast route management is used to manage the multicast routing table, and create or change
multicast RPF routes.
6.2 IP Multicast Routing Management Features Supported

by the NE5000E
The NE5000E supports multicast static routes and multicast load splitting.
Multicast Static Routes

Multicast static routes are important basis of an RPF check. By configuring multicast static
routes, you can specify an RPF interface and an RPF neighbor for the specific source of packets
on the current router.
Multicast static routes have the functions of changing RPF routes and connecting RPF routes
rather than being used for data forwarding. Multicast static routes take effect only on the
multicast router where they are configured, and cannot be advertised or imported to other
routers.
Multicast Load Splitting

In choosing an upstream interface, a multicast router prefers the optimal route by default. If there
are multiple optimal routes, the route with a higher next-hop address is choosen. If there are
multiple equal-cost unicast routes, you can configure different policies of implementing
multicast load splitting among these routes.

There are four multicast load splitting policies: stable-preferred, source address-based, group
address-based, and source and group addresses-based. The four load splitting policies are
mutually exclusive.
Control over the Multicast Forwarding Scope

On a network, the multicast information to which each multicast group corresponds should be
transmitted in a certain range. You can define the multicast forwarding scope by using the
following methods:
l Setting the forwarding TTL threshold on an interface to limit the distance to which a packet
is forwarded.
l Prohibiting an interface from receiving multicast packets. The router then cannot exchange
multicast protocol packets through this interface and the multicast forwarding scope is thus
limited.
Control over the Capacity of a Multicast Forwarding Table

When planning a specific network according to network services, an Internet Service Provider
(ISP) can perform the following configuration:
l Limiting the number of entries in a multicast forwarding table

The router maintains a forwarding entry for each received multicast packet. Too many
multicast forwarding entries, however, use up the memory of the router. Thus, you can
define the maximum number of entries in the multicast forwarding table of theNE5000E.
Limiting the number of entries according to the actual networking and service performance
can avoid router faults caused by too many entries.
l Limiting the number of downstream interfaces of a single forwarding entry
The NE5000E replicates a copy of multicast packet for each downstream interface and
sends it out. Each downstream interface forms a branch of an MDT. The number of
downstream interfaces determines the scale of the MDT and the multicast service range.
You can define the number of downstream interfaces of a single forwarding entry. Limiting
the number of downstream interfaces according to the actual networking and service
performance can reduce the processing pressure of the router and control the service range.
Multicast Multi-Topology
Multi-topology is a type of network structure, featuring different logical topologies for diverse
services on one physical network. Currently, multicast multi-topology is one of typical
applications. The system generates a multicast multi-topology routing table dedicated for
multicast services so that multicast routing no longer completely depends on the unicast routing
table. Thus, the problem that unicast routes restrict the establishment of an MDT is solved. Then,
when a multicast router performs the RPF check, it searches for routes and establishes a multicast
forwarding tree only in the specified topology running for multicast data forwarding.
6.3 Configuring RPF Routes

A multicast routing protocol creates multicast routing entries based on the RPF mechanism and
then establishes an MDT.

The RPF check is a basis of multicast routing. The process of performing an RPF check is as
follows:
1. According to the source of a packet, a router searches its unicast routing table and multicast
static routing table for optimal routes.
2. The router selects a route with the highest priority from the multiple optimal routes as an
RPF route. If the inbound interface of the packet is identical with the RPF interface, the
packet passes the RPF check; otherwise, the packet fails the RPF check.
If the priorities of the optimal routes are the same, the router selects the route in the sequence
of the multicast static route and unicast route.
By configuring multicast static routes, you can specify an RPF interface and an RPF neighbor
for the specific source of packets.
In choosing an upstream interface, a multicast router prefers the route with the highest next-hop
address by default. If there are multiple equal-cost unicast routes, you can configure different
policies of implementing multicast load splitting among these routes and designating different
upstream interfaces for different multicast entries. In this manner, the transmission of multiple
multicast data flows over a network is optimized.
Before configuring RPF routes, complete the following tasks:
6.3.1 Configuring Multicast Static Routes

Multicast static routes are an important basis of the RPF check. By configuring multicast static
routes, you can specify an RPF interface and an RPF neighbor for the specific source of packets
on the current router.
Context
Multicast static routes provide the following functions, depending on specific applicable
environments:
l Changing RPF routes
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. You can configure multicast static routes to change
the RPF routes. Thus, a transmission path dedicated for the multicast data is established,
which is different from the transmission path of unicast data.
l Connecting RPF routes
On 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. In such a case,

you can configure multicast static routes. Therefore, the system can generate RPF routes,
complete the RPF check, create routing entries, and guide the forwarding of packets.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip rpf-route-static [ vpn-instance vpn-instance-name ] source-address { mask | mask-
length } [ protocol [ process-id ] ] [ route-policy route-policy-name ] { rpf-
neighbor | interface-type interface-number } [ preference preference ] [ order
order-number ]
A multicast static route is configured.
NOTE
If the next-hop interface is a P2P interface, you must configure the outbound interface, that is, the RPF
interface by using the interface-type interface-number parameter in the command.
If the next-hop interface is not a P2P interface, you must configure the next-hop address, that is, the IP
address of the RPF neighbor by using the rpf-nbr parameter in the command.
l source-address { mask | mask-length }: specifies a multicast source address and mask.
l protocol [ process-id ]: specifies that the matching route must be present in the specified
unicast routing protocol. protocol specifies a unicast routing protocol and process-id
specifies the ID of a process.
l route-policy policy-name: specifies the matching rule of the multicast static route.
l preference preference: specifies the preference of the multicast static route. The greater the
value, the lower the preference.
l order order-num: specifies the configuration order of routes on the same network segment.
Parameters source-address { mask | mask-length }, protocol, and route-policy policy-name are

key factors of multicast static routes. As long as one parameter is configured differently each
time, the configuration is considered as a new configuration. A maximum of eight different
configurations are allowed on a network segment.
Step 3 Run:
commit
----End
Follow-up Procedure
After the ip rpf-route-static command is configured, the multicast static route may not take
effect. This is because the outbound interface may not be iterated or the specified interface may
be Down. Therefore, after configuring the multicast static route, you are recommended to run
the display ip routing-table table msr command to check whether the route is configured
successfully or whether the route takes effect.

6.3.2 Configuring Multicast Load Splitting

Multicast load splitting is applicable to the scenario where multiple equal-cost unicast routes of
the same type exist. In such a case, multicast load splitting can be performed according to
different policies to optimize the transmission of multiple multicast data flows on the network.
Context
CAUTION
The configuration related to the VPN instance is applicable only to the PE. If you want to
configure multicast load splitting for a VPN instance on the PE, you must perform the
configuration in the VPN instance view. For other cases, you need to perform the configuration
in the public network instance view.
The RPF check is a basis of multicast routing. According to RPF rules, the router selects a unique
route for multicast data forwarding. If multicast traffic is overloaded, network congestion may
occur and the multicast service is thus interrupted.
The multicast load splitting function extends multicast routing rules and multicast routing no
long fully depends on the RPF check. If there are multiple equal-cost optimal routes, multicast
traffic is load split to these equal-cost routes.
Procedure
l Public network instance
1. Run:
system-view

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

stable-preferred: indicates stable-preferred load splitting. This policy is
applicable to a stable multicast networking.
If stable-preferred is specified, the router automatically adjusts and balances the
entries when equal-cost routes are added or deleted; however, the router does not
automatically adjust and balance the entries when multicast routing entries are
deleted.
group: indicates group address-based load splitting. This policy is applicable to
the scenario of one source to multiple groups.
source: indicates source address-based load splitting. This policy is applicable to
the scenario of one group to multiple sources.
source-group: indicates source and group addresses-based load splitting. This
policy is applicable to the scenario of multiple sources to multiple groups.
3. Run:
commit


l VPN instance
1. Run:
system-view

2. Run:

3. Run:
multicast load-splitting { stable-preferred | source | group | source-
group }
Multicast load splitting is configured.

4. Run:
commit
----End

After RPF routes are configured, you can run commands to view configurations of the RPF
routes.
Prerequisite
All configurations of RPF routes are complete.
Procedure
Step 1 Run the display multicast [ vpn-instance vpn-instance-name | all-instance ] rpf-info source-
address [ group-address ] [ rpt | spt ] command to check information about the source-specific
RPF route.
----End
Example
Run the display multicast rpf-info source-address command, and you can view RPF routing
information about a specified multicast source, including the RPF interface, RPF neighbor,
optimal route and type of the route, and configured multicast load splitting policy. For example:
<HUAWEI> display multicast rpf-info 172.168.0.1
RPF information about source: 172.168.0.1
RPF interface: GigabitEthernet6/0/0, RPF neighbor: 11.1.5.2
Referenced route/mask: 172.168.0.0/24
Referenced route type: unicast
Route selection rule: preference-preferred
Load splitting rule: stable-preferred

6.4 Adjusting the Minimum TTL Value for Multicast

Forwarding
Multicast information of each multicast group in a network should be transmitted within a certain
range. Therefore, setting the minimum TTL value for multicast forwarding is necessary for
limiting the multicast data forwarding scope.
Setting the minimum TTL value for multicast forwarding on an interface to limit the distance
to which a packet is forwarded. The interface forwards only the packets (including those
generated by the local device) with the TTL value being equal to or greater than the minimum
TTL value. If the TTL value of a packet is smaller than the minimum TTL value, the interface
discards the packet.
Before adjusting the minimum TTL value for multicast forwarding, complete the following
tasks:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
multicast minimum-ttl ttl-value
The minimum TTL value for multicast forwarding is set.

By default, the minimum TTL value is 1.
Step 4 Run:
commit
----End

Run the display multicast [ vpn-instance vpn-instance-name | all-instance ] minimum-ttl
interface-type interface-number command to check the minimum TTL value for multicast
forwarding on the interface.


Examples for configuring multicast static routes, multicast load splitting, and multicast multi-
topology are provided.
6.5.1 Example for Configuring Multicast Static Routes to Change

RPF Routes
By configuring multicast static routes in the multicast network, you can change the RPF route
and create a multicast path different from the unicast path, from the multicast source to the
receiver.
CAUTION
As shown in Figure 6-1, the network runs PIM-SM, all routers support multicast, and the receiver
can receive information from the multicast source. IS-IS is run between routers. It is required to
configure a multicast static route to make the multicast path from the source to the receiver
different from the unicast path from the source to the receiver.

Figure 6-1 Networking diagram for configuring multicast static routes to change RPF routes
RouterC POS2/0/0 POS2/0/0

13.1.1.2/24 13.1.1.1/24
RouterB
POS3/0/0 /0 POS3/0/0
12.1.1.2/24 S 1/0 24 10.1.1.2/24
PO .1.2/
POS3/0/0 9.1 POS3/0/0
12.1.1.1/24 0
/0/ 10.1.1.1/24
O S1 1/24
RouterA P .1.
9.1 RouterD
GE2/0/0
8.1.1.1/24 GE2/0/0
PIM-SM 7.1.1.1/24
8.1.1.2/24 7.1.1.2/24
Source Receiver
multicast static route
Configuration Notes
When configuring multicast static routes to change RPF routes, pay attention to the following
points:
l When you configure a multicast static route, if the next hop is a P2P interface, you must
specify the outbound interface number; if the next hop is not a P2P interface, you must
specify the next-hop address.
1. Configure IP addresses for the interfaces on each router and configure IS-IS on them.
2. Enable the multicast function on all routers, enable PIM-SM on each interface, and enable
IGMP on the interfaces connecting routers to hosts.
3. Configure C-BSRs and C-RPs.
4. Configure multicast static routes on Router B and specify Router C as an RPF neighbor to
the source.

Data Preparation
l IP address of the source
l Outbound interface of Router B to the source
Procedure
Step 1 Configure IP addresses for the interfaces on each router and configure a unicast routing protocol.
Step 2 Enable the multicast function on all routers and enable PIM-SM on each interface.
# The configurations on Router B, Router C, and Router D are similar to those on Router A and

# Enable IGMP on the interface connecting Router D to hosts.

# Configure POS 3/0/0 on Router C as both a C-BSR and a C-RP.
[~RouterC] pim
[~RouterC] c-bsr pos 3/0/0
[~RouterC] c-rp pos 3/0/0
[~RouterC] commit
[~RouterC] quit
# Run the display multicast rpf-info command on Router B to view the RPF information of
the source. You can find that the RPF route is a unicast route, and the RPF neighbor is Router
A. The display is as follows:
<RouterB> display multicast rpf-info 8.1.1.2
RPF information about source 8.1.1.2:
RPF interface: Pos1/0/0, RPF neighbor: 9.1.1.1
Load splitting rule: disable
Step 5 Configure multicast static routes

# Configure a multicast static route on Router B and specify Router C as an RPF neighbor to
the source.

<RouterB> system-view
[~RouterB] ip rpf-route-static 8.1.1.0 255.255.255.0 13.1.1.2
[~RouterB] commit
[~RouterB] quit
# Run the display multicast rpf-info command on Router B to view the RPF information of
the source. You can find that the RPF route and the RPF neighbor are updated according to the
multicast static route. The display is as follows:
Referenced route type: mstatic
----End
Configuration Files
#
sysname RouterA
#
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 8.1.1.1 255.255.255.0
pim sm
isis enable 1
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 9.1.1.1 255.255.255.0
pim sm
isis enable 1
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 12.1.1.1 255.255.255.0
pim sm
isis enable 1
#
return

#
sysname RouterB
#
#
isis 1
network-entity 10.0000.0000.0002.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp

ip address 9.1.1.2 255.255.255.0

pim sm
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 13.1.1.1 255.255.255.0
pim sm
isis enable 1
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
pim sm
isis enable 1
#
ip rpf-route-static 8.1.1.0 255.255.255.0 13.1.1.2
#
return
#
sysname RouterC
#
#
isis 1
network-entity 10.0000.0000.0003.00
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 13.1.1.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 12.1.1.2 255.255.255.0
pim sm
isis enable 1
#
pim
c-bsr Pos3/0/0
c-rp Pos3/0/0
#
return
#
sysname RouterD
#
#
isis 1
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 7.1.1.1 255.255.255.0
pim sm
igmp enable
isis enable 1
#
interface Pos3/0/0
undo shutdown
link-protocol ppp

ip address 10.1.1.1 255.255.255.0

pim sm
isis enable 1
#
return
6.5.2 Example for Configuring Multicast Static Routes to Connect

RPF Routes
After multicast static routes are configured in the multicast network, a receiver can receive
multicast data from a multicast source in another area that is unreachable with unicast routes.
CAUTION
As shown in Figure 6-2, the network runs PIM-SM, all routers support multicast, and the receiver
can receive information from Source1. Router B and Router C run OSPF. There is no unicast
route between Router A and Router B. It is required that a multicast static route be configured
to enable the receiver to receive information sent from Source2.
Figure 6-2 Networking diagram for configuring multicast static routes to connect RPF routes
PIM-SM
OSPF
Source1
10.1.3.2/24
GE2/0/0
10.1.3.1/24 POS3/0/0 POS3/0/0 RouterA
10.1.4.1/24 10.1.4.2/24
RouterB
POS1/0/0
10.1.2.2/24 POS1/0/0 GE1/0/0
10.1.2.1/24 10.1.5.1/24
RouterC
Source2
GE2/0/0 10.1.5.2/24
10.1.1.1/24
Receiver
multicast static route

Configuration Notes
When configuring multicast static routes to connect RPF routes, pay attention to the following
points:
l When configure a multicast static route, if the next hop is a P2P interface, you must specify
the outbound interface number; if the next hop is not a P2P interface, you must specify the
next-hop address.
1. Configure IP addresses for the interfaces on each router and configure OSPF on each
router.
2. Enable the multicast function on all routers, enable PIM-SM on each interface, and enable
IGMP on the interfaces connecting routers to hosts.
3. Configure C-BSRs and C-RPs.
4. Configure multicast static routes on Router B and Router C.
Data Preparation
l IP address of Source2
l RPF interface connecting Router B to Source2 and the RPF neighbor of Router B
l RPF interface connecting Router C to Source2 and the RPF neighbor of Router C
Procedure
Step 1 Configure IP addresses for the interfaces on each router and configure a unicast routing protocol.
# Configurations on Router A and Router C are similar to those on Router B and hence are not
mentioned here.
[~RouterB] interface gigabitethernet 2/0/0
[~RouterB-GigabitEthernet2/0/0] pim sm
[~RouterB-GigabitEthernet2/0/0] quit

# Enable IGMP on the interface connecting Router C to hosts.


[~RouterC-GigabitEthernet2/0/0] commit

# Configure POS 1/0/0 on Router B as both a C-BSR and a C-RP.
[~RouterB] pim
[~RouterB] c-bsr pos 1/0/0
[~RouterB] c-rp pos 1/0/0
[~RouterB] commit
[~RouterB] quit
Source1 (10.1.3.2/24) and Source2 (10.1.5.2/24) both send multicast data to G (225.1.1.1). The
receiver joins G and can receive multicast data sent from Source1 and Source2.
# Run the display multicast rpf-info 10.1.5.2 command on Router B and Router C but there is
no command output. This indicates that Routers have no RPF routes to Source2.
Step 5 Configure multicast static routes.
# Configure a multicast static route on Router B and specify Router A as an RPF neighbor to
Source2.
<RouterB> system-view
[~RouterB] ip rpf-route-static 10.1.5.0 255.255.255.0 10.1.4.2
[~RouterB] commit
[~RouterB] quit
# Configure a multicast static route on Router C and specify Router B as an RPF neighbor to
Source2.
<RouterC> system-view
[~RouterC] ip rpf-route-static 10.1.5.0 255.255.255.0 10.1.2.2
[~RouterC] commit
[~RouterC] quit

# Run the display multicast rpf-info 10.1.5.2 command again on Router B and Router C, and
you can view RPF information of Source2. RPF information is as follows:
RPF information about: 10.1.5.2
Route selecting rule: preference-preferred
<RouterC> display multicast rpf-info 10.1.5.2
# Run the display pim routing-table command on Router C to view information about the PIM
routing table. Router C has multicast entries related to Source2 and the receiver can receive
multicast data from Source2.


(*, 225.1.1.1)
RP: 10.1.2.2
Protocol: PIM-SM, Flag: WC
UpTime: 03:54:19
Protocol: PIM-SM, UpTime: 01:38:19, Expires: never
(10.1.3.2, 225.1.1.1)
RP: 10.1.2.2
Protocol: PIM-SM, Flag: ACT
UpTime: 00:00:44
(10.1.5.2, 225.1.1.1)
RP: 10.1.2.2
Protocol: PIM-SM, Flag: ACT
UpTime: 00:00:44
----End
Configuration Files
#
sysname RouterA
#
#
undo shutdown
ip address 10.1.5.1 255.255.255.0
pim sm
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 10.1.4.2 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.1.5.0 0.0.0.255
network 10.1.4.0 0.0.0.255
#
return

#
sysname RouterB
#

#
undo shutdown
ip address 10.1.3.1 255.255.255.0
pim sm
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.2.2 255.255.255.0
pim sm
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 10.1.4.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
#
pim
c-bsr Pos3/0/0
c-rp Pos3/0/0
#
ip rpf-route-static 10.1.5.0 24 10.1.4.2
#
return

#
sysname RouterC
#
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
pim sm
igmp enable
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
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
#
ip rpf-route-static 10.1.5.0 24 10.1.2.2
#
return
6.5.3 Example for Configuring Multicast Load Splitting

On a PIM-SM network where multicast services are stable, it is required to configure the stable-
preferred multicast load splitting policy so that multicast traffic can be distributed to multiple
equal-cost routes for transmission.

CAUTION
interface number. In the NE5000E cluster, an interface is numbered in the format of chassis ID/
slot number/card number/interface number. If the slot number is specified, the chassis ID of the
slot must also be specified.
As shown in Figure 6-3, there are three equal-cost routes from the device connected with Host
A to Source. Host A needs to stably receive multicast data for a long term from the source. It is
required to configure a load splitting policy to distribute entries evenly to the three equal-cost
routes. In this manner, load splitting among equal-cost routes is implemented.
Figure 6-3 Networking diagram of configuring multicast load splitting
PIM-SM
Source
0 POS
2/ 0/1 S1/0/ 2/0/ POS
1/0/
GE1/0/0 PO S PO RouterB 0 1
POS2/0/2 POS1/0/2
RouterA POS RouterE
2/0/ POS1/0/0 POS2/0/0 0/3
3 S1/
RouterC PO POS2/0/0
POS 0/0 POS2/0/0
1/0/
0 S2/
Loopback0 PO
RouterD GE1/0/0
RouterF
HostA
Router A GE 1/0/0 10.110.1.2/24 Router D POS 1/0/0 192.168.3.2/24
POS 2/0/1 192.168.1.1/24 POS 2/0/0 192.168.6.1/24
POS 2/0/2 192.168.2.1/24 Router E POS 1/0/1 192.168.4.2/24
POS 2/0/3 192.168.3.1/24 POS 1/0/2 192.168.5.2/24
Loopback0 1.1.1.1/32 POS 1/0/3 192.168.6.2/24
Router B POS 1/0/0 192.168.1.2/24 POS 2/0/0 192.168.7.1/24
POS 2/0/0 192.168.4.1/24 RouterF GE 1/0/0 10.110.2.2/24
Router C POS 1/0/0 192.168.2.2/24 POS 2/0/0 192.168.7.2/24
POS 2/0/0 192.168.5.1/24

Configuration Notes
When configuring multicast splitting, pay attention to the following points:
l The four types of load splitting policies are mutually exclusive. So, you can configure one
of them according to the actual situation.
1. Configure IP addresses for the interfaces on each router.
2. Configure IS-IS to implement intercommunications among routers and ensure that route
costs are equal.
3. Enable the multicast function on all the routers, enable PIM-SM on each interface, and set
the loopback interface on Router A as an RP.
4. Configure stable-preferred multicast load splitting on Router E.
5. Host A requires to receive data from some multicast groups for a long period. Configure
the interfaces at the host side of Router F to statically join the multicast groups.
Data Preparation
l IP address of Source
l IP address of each interface on the router
l Addresses of the multicast groups that the interfaces at the host side of Router F statically
join
Procedure
Step 1 Configure IP addresses for the interfaces on each router according to Figure 6-3. The detailed
configuration procedure is not mentioned here.
Step 2 Configure IS-IS to implement intercommunications among routers and ensure that route costs
are equal. The detailed configuration procedure is not mentioned here.
# Configurations on Routers B, C, D, E, and F are similar to those on RouterA. Therefore,
configurations on these routers are not mentioned here.


[~RouterA-LoopBack0] pim sm
[~RouterA-LoopBack0] commit
Step 4 Enable IGMP on the interfaces connecting routers to hosts.
# Enable IGMP on the interfaces connecting Router F to hosts.

[~RouterF] interface gigabitethernet 1/0/0
[~RouterF-GigabitEthernet1/0/0] igmp enable
[~RouterF-GigabitEthernet1/0/0] commit
[~RouterF-GigabitEthernet1/0/0] quit
Step 5 Configure an RP on Router A.
# Configure loopback0 on Router A as an RP.

[~RouterA] pim
[~RouterA-pim] c-bsr loopback 0
[~RouterA-pim] c-rp loopback 0
[~RouterA-pim] quit
Step 6 Configure stable-preferred multicast load splitting on Router E.

[~RouterE] multicast load-splitting stable-preferred
[~RouterE] commit
Step 7 Add the interfaces connecting routers to hosts to the multicast groups statically.
# Statistically add GE 1/0/0 on Router F to the multicast groups from 225.1.1.1 to 225.1.1.3.
[~RouterF] interface gigabitethernet 1/0/0
[~RouterF-GigabitEthernet1/0/0] igmp static-group 225.1.1.1
[~RouterF-GigabitEthernet1/0/0] commit
[~RouterF-GigabitEthernet1/0/0] quit
# Source (10.110.1.1/24) sends multicast data to multicast groups 225.1.1.1 to 225.1.1.3. Host
A can receive the multicast data sent from Source. On Router E, check information about the
PIM routing table.
<RouterE> display pim routing-table brief
Total 3 (*, G) entries; 3 (S, G) entries
Entries Upstream interface NDwnstrms

(*, 225.1.1.1) Pos1/0/3 1
(10.110.1.1, 225.1.1.1) Pos1/0/3 1
(*, 225.1.1.2) Pos1/0/2 1
(10.110.1.1, 225.1.1.2) Pos1/0/2 1
(*, 225.1.1.3) Pos1/0/1 1
(10.110.1.1, 225.1.1.3) Pos1/0/1 1
(*, G) and (S, G) entries are evenly distributed to the three equal-cost routes, with the upstream
interfaces being POS 1/0/3, POS 1/0/2, and POS 1/0/1 respectively.

NOTE
The load splitting algorithm processes (*, G) and (S, G) entries separately but the process rules are the
same.
----End
Configuration Files
#
sysname RouterA
#
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 10.110.1.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/1
undo shutdown
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/2
undo shutdown
link-protocol ppp
ip address 192.168.2.1 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/3
undo shutdown
link-protocol ppp
ip address 192.168.3.1 255.255.255.0
pim sm
isis enable 1
#
interface Loopback0
ip address 1.1.1.1 255.255.255.255
pim sm
isis enable 1
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
return

#
sysname RouterB
#
#
isis 1
network-entity 10.0000.0000.0002.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp

ip address 192.168.1.2 255.255.255.0

pim sm
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.4.1 255.255.255.0
pim sm
isis enable 1
#
return
#
sysname RouterC
#
#
isis 1
network-entity 10.0000.0000.0003.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.2.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.5.1 255.255.255.0
pim sm
isis enable 1
#
return
#
sysname RouterD
#
#
isis 1
network-entity 10.0000.0000.0004.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 192.168.3.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.6.1 255.255.255.0
pim sm
isis enable 1
#
return
#
sysname RouterE
#
multicast load-splitting stable-preferred
#

isis 1
network-entity 10.0000.0000.0005.00
#
interface Pos1/0/1
undo shutdown
link-protocol ppp
ip address 192.168.4.2 255.255.255.0
isis enable 1
pim sm
#
interface Pos1/0/2
undo shutdown
link-protocol ppp
ip address 192.168.5.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos1/0/3
undo shutdown
link-protocol ppp
ip address 192.168.6.2 255.255.255.0
pim sm
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.7.1 255.255.255.0
pim sm
isis enable 1
#
return
l Configuration file of the Router F

#
sysname RouterF
#
#
isis 1
network-entity 10.0000.0000.0006.00
#
undo shutdown
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.168.7.2 255.255.255.0
pim sm
isis enable 1
#
return

Configuration Guide - IP Multicast 7 MLD Configuration
7 MLD Configuration
About This Chapter
To manage multicast group members on a local IPv6 network, configure MLD on the interface
that connects a multicast device to a user network segment.
7.1 MLD Overview

MLD is short for Multicast Listener Discovery. It has two versions: MLDv1 and MLDv2.
MLDv1 supports the ASM model and MLDv2 supports the SSM model.
7.2 MLD Features Supported by the NE5000E
The supported MLD features include basic MLD functions, Router-Alert options, MLD querier
parameter settings, and SSM mapping.
7.3 Configuring Basic MLD Functions
After basic MLD functions are configured on the interfaces connecting multicast devices to the
7.4 Configuring MLD SSM Mapping
On an IPv6 network providing multicast SSM services, an interface on a multicast router runs
MLDv2 but user hosts run MLDv1 due to some causes. To ensure that MLD versions on a
multicast device and user hosts are compatible and enable the multicast router running a higher
version of MLD to provide SSM services for its directly connected user hosts running a lower
version of MLD, configure SSM mapping on the multicast router.
7.5 Configuring an MLD Router-Alert Option
In this configuration task, you can configure a device to deny all the MLD packets without
Router-Alert options or send MLD packets without Router-Alert options.
7.6 Configuring an MLD Querier
Configuring an MLD querier involves setting the interval for sending general query messages,
robustness variable, maximum response time of Query messages, Keepalive time of other MLD
queriers, and interval for sending MLD last-listener query messages, and configuring the MLD
prompt leave function.
7.7 Maintaining MLD
Maintaining MLD involves resetting MLD group information, monitoring MLD operating
status, and debugging MLD.


Configuration examples show you how to configure basic MLD functions and how to configure
MLD SSM mapping.

7.1 MLD Overview

MLD is short for Multicast Listener Discovery. It has two versions: MLDv1 and MLDv2.
MLDv1 supports the ASM model and MLDv2 supports the SSM model.
The Multicast Listener Discovery (MLD) is a sub-protocol of the Internet Control Message
Protocol version 6 (ICMPv6). MLD is used to set up and maintain group memberships between
user hosts and their directly connected multicast devices. The functions and principles of MLD
are similar to those of IGMP.
MLD has two versions:
l MLDv1 (defined in RFC 2710)

MLDv1 is derived from IGMPv2 and supports the Any-Source Multicast (ASM) model.
With the help of SSM mapping, MLDv1 supports the Source-Specific Multicast (SSM)
model.
l MLDv2 (defined in RFC 3810)
MLDv2 is derived from IGMPv3 and supports ASM and SSM models.
7.2 MLD Features Supported by the NE5000E

The supported MLD features include basic MLD functions, Router-Alert options, MLD querier
parameter settings, and SSM mapping.
Basic MLD Functions

The NE5000E supports the following basic MLD functions:
l Configuration of MLDv1 and MLDv2

l Adding of an interface that is to be added to a multicast group statically After an interface
is added to a multicast group statically, the system considers that the network segment
where the interface resides contains a group member.
l Limit on the range of multicast groups to which an interface can be added
MLD supports multicast packets without local receivers to be delivered to the upper-layer
protocol for processing by adding Router-Alert options to the packets.
You can determine whether to enable the NE5000E to send MLD packets with Router-Alert
options or enable the NE5000E to accept only MLD packets with Router-Alert options.
MLD Querier Parameter Settings

You can configure the following parameters:
l Interval for sending MLD general query messages

l MLD robustness variable
l Maximum response time of MLD Query messages

l Keepalive time of other MLD queriers

l Interval for sending MLD last-listener query messages
l MLD prompt leave feature
After receiving a Done message for a certain multicast group, the interface enabled with
prompt leave directly deletes the records of the multicast group without sending a last-
listener query message.
SSM Mapping
SSM mapping enables multicast devices to provide SSM services for user hosts that run MLDv1.
7.3 Configuring Basic MLD Functions

After basic MLD functions are configured on the interfaces connecting multicast devices to the
MLD runs on the network segment where the router is directly connected to user hosts. It must
be configured on both the router and user hosts. This section describes how to configure MLD
on the router.
Before configuring MLD, enable IPv6 multicast routing. IPv6 multicast routing is the
precondition for configuring all IPv6 multicast functions. If IPv6 multicast routing is disabled,
all IPv6 multicast-related configurations are deleted.
MLD needs to be enabled on the interfaces connected to user hosts. Specify matching MLD
versions for the router and attached user hosts because the packet formats of MLDv1 and MLDv2
are different. The MLD version at the router side must be of a higher version and be compatible
with the lower version at the host side. Other MLD-related configurations can be performed only
after MLD versions are specified.
In addition, by configuring interfaces on the router to statically join an MLD group, enable the
router to rapidly respond to users' requests, thereby shortening channel switching time.
To make hosts on the network segment where interfaces of the router reside join specified MLD
groups and receive multicast packets for these groups, define an ACL rule as a filter to restrict
the range of MLD groups that the hosts can join. This guarantees MLD security.
Before configuring basic MLD functions, complete the following tasks:
l Configuring link layer protocol parameters and assigning IPv6 addresses to interfaces to
ensure that the status of the link layer protocol on the interfaces is Up

Figure 7-1 Flowchart for configuring basic MLD functions
Enable IPv6 multicast routing
Enable IPv6 PIM-SM
Enable MLD
Set an MLD version
Configure an interface to statically

join an MLD group
Set the range of MLD groups that

an interface can join
Mandatory
procedure
Optional
procedure
7.3.1 Enabling IPv6 Multicast Routing

Before configuring IPv6 multicast features in a router, enable IPv6 multicast routing on the
router.
Procedure
Step 1 Run:
system-view

Step 2 Run:
multicast ipv6 routing-enable
IPv6 multicast routing is enabled.
CAUTION
Running the undo multicast ipv6 routing-enable command clears all IPv6 multicast
configurations and interrupts running IPv6 multicast services. To restore the IPv6 multicast
services, you need to run the IPv6 multicast commands that have been deleted.

Step 3 Run:
commit
----End
7.3.2 Enabling IPv6 PIM-SM

After IPv6 PIM-SM is enabled on the interface connected to other routers, the interface can
establish IPv6 PIM neighbor relationships with the routers.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim ipv6 sm
IPv6 PIM-SM is enabled.
CAUTION
Running the undo pim ipv6 sm command clears the IPv6 PIM neighbors of an interface. If the
interface is running IPv6 multicast services, running the command will interrupt the services on
the interface.
Step 4 Run:
commit
----End
7.3.3 Enabling MLD

User hosts can dynamically join MLD groups after MLD is enabled on the interfaces connected
to user network segments.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mld enable
MLD is enabled.
MLD parameters configured on the interface before MLD is enabled on this interface take effect
only after the mld enable command is run on the interface.
Step 4 Run:
commit
----End
7.3.4 (Optional) Setting an MLD Version

MLD version; otherwise, multicast devices fail to communicate with each other.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mld version { 1 | 2 }
An MLD version is set for the interface.

By default, MLDv2 is run on the interface.
Step 4 Run:
commit
----End
7.3.5 (Optional) Configuring an Interface to Statically Join an MLD

Group
After an interface connecting the multicast device to a user network segment is configured to
statically join an MLD group, the multicast device always considers that the interface has an
attached multicast group member and continues forwarding required multicast packets to this
interface.

Context
If a user network segment has stable IPv6 hosts that demand multicast programs, configure the
interface connected to the user network segment to statically join an MLD group This ensures
that the interface can rapidly respond to users' requests and shortens channel switching time.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mld static-group ipv6-group-address [ inc-step-mask ipv6-group-mask-length number
group-number ] [ source ipv6-source-address ]
The interface is configured to statically join an MLD group.

The mld static-group command must be run on the interfaces connected to user hosts. The
interface can be added to a single IPv6 multicast group or source/group, or be added to multiple
IPv6 multicast groups or source/groups in batches.
After the interface is configured to statically join an MLD group, multicast entries generated on
the router never time out. Therefore, the router keeps forwarding multicast data to the interface.
If the interface no longer needs to receive IPv6 multicast data for the group, the static MLD
group configurations must be deleted manually from the interface.
Step 4 Run:
commit
----End
7.3.6 (Optional) Setting the Range of MLD Groups that an Interface

Can Join
After an MLD group policy is configured on the interfaces connected to user network segments,
user hosts can join certain MLD groups.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mld group-policy { acl6-number | acl6-name acl6-name } [ 1 | 2 ]
The range of MLD groups that the interface can join is set.
By default, hosts can join any MLD group.
Step 4 Run:
commit
----End

After basic MLD functions are configured, check the configurations and operating status of
MLD and information about MLD group members.
Prerequisite
All basic MLD function configurations are complete.
Procedure
l Run the display mld interface [ interface-type interface-number | up | down ]
[ verbose ] command to view the configurations and operating status of MLD on an
interface.
l Run the display mld group [ ipv6-group-address | interface interface-type interface-
number ] * [ static ] [ verbose ] command to view information about MLD group members.
----End
Example
Run the display mld interface gigabitethernet 1/0/0 verbose command, and you can see
detailed MLD configurations on GE 1/0/0. For example:
<HUAWEI> display mld interface gigabitethernet 1/0/0 verbose
Interface information
GigabitEthernet1/0/0(FE80::2E0:B4FF:FE35:FF01):
MLD is enabled
Current MLD version is 2
MLD state: up
MLD group policy: none
Value of query interval for MLD (negotiated): 125 s
Value of query interval for MLD (configured): 125 s
Value of other querier timeout for MLD: 0 s
Value of maximum query response time for MLD: 10 s
Value of last listener query time: 2 s
Value of last listener query interval: 1 s
Querier for MLD: FE80::2E0:B4FF:FE35:FF01 (this router)
MLD activity: 0 joins, 0 dones
Robustness (negotiated): 2

SSM-Mapping: disabled
Startup-query-timer-expiry: on
Total 2 MLD Groups reported
Run the display mld group verbose command, and you can see details about the MLD groups
that interfaces dynamically join. For example:
<HUAWEI> display mld group verbose
GigabitEthernet6/0/2(FE80::2E0:49FF:FE29:1103):
Total 1 MLD Group reported
Group: FF05::2
Uptime: 00:01:07
Expires: 00:03:45
Last reporter: FE80::215:E9FF:FEAC:7666
Last-listener-query-counter: 0
Last-listener-query-timer-expiry: off
Group mode: exclude
Run the display mld group static command, and you can see information about the MLD groups
that interfaces statically join. For example:
<HUAWEI> display mld group static
Static join group information of VPN-Instance: public net
Ethernet1/0/0:
Total 1 MLD entry
FF30::101 1:1:1::101 never
Ethernet2/0/1:
Total 2 MLD entries
FF00:1232:4561: 1234:1232:4561: never
7896:3456:6666: 7896:3456:6666:
1234:3456 1234:3456
FF30::103 1:1:1::103 never
7.4 Configuring MLD SSM Mapping

MLDv2 but user hosts run MLDv1 due to some causes. To ensure that MLD versions on a
multicast device and user hosts are compatible and enable the multicast router running a higher
version of MLD to provide SSM services for its directly connected user hosts running a lower
version of MLD, configure SSM mapping on the multicast router.
MLDv2 but user hosts run MLDv1 due to some causes. To enable the multicast router to provide
SSM services for the user hosts, configure SSM mapping on the router.
Before configuring MLD SSM mapping, complete the following tasks:

l 7.3 Configuring Basic MLD Functions

Figure 7-2 Flowchart for configuring MLD SSM mapping
Enable the SSM mapping

function
Configure IGMP SSM

mapping
Mandatory
procedure
Optional
procedure
7.4.1 Enabling the SSM Mapping Function

Enabling the SSM mapping function on an interface connecting to a user network segment is a
prerequisite for configuring MLD SSM mapping. The SSM source/group address mapping
entries configured on the interface take effect only after SSM mapping is enabled on the interface.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mld version 2
The MLD version is set to 2.

To ensure that all user hosts (running any MLD version) can obtain SSM services, MLDv2 is
recommended. By default, an interface runs MLDv2.
Step 4 Run:
mld ssm-mapping enable
The SSM mapping function is enabled.

Step 5 Run:
commit
----End
7.4.2 Configuring Static SSM Mapping

The SSM mapping function configured on a multicast device connected to a user network
segment allows user hosts that support only MLDv1 to join specific source/groups. It implements

MLD version compatibility on the multicast device and user hosts and enables the multicast
device to provide SSM services for all the user hosts.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mld
The MLD view is displayed.
Step 3 Run:
ssm-mapping ipv6-group-address ipv6-group-mask-length ipv6-source-address
A mapping from an MLD group to a source is created.
l ipv6-group-address ipv6-group-mask-length specifies an MLD group address and mask,

which must be in the SSM group address range. By default, the SSM group address range is
FF3x::/32. You can run the ssm-policy command to set an SSM group address range out of
this range.
l ipv6-source-address specifies an IPv6 multicast source address mapped to the MLD group
address.
You can run the ssm-mapping command for several times to map the same MLD group to
multiple sources.
Step 4 Run:
commit
----End

After MLD SSM mapping is configured, check information about the groups configured with
SSM mapping, SSM mapping rules of a specified group, and SSM mapping status to ensure
normal operating of the SSM mapping function.
Prerequisite
All MLD SSM mapping configurations are complete.
Procedure
interface.
number ] * ssm-mapping [ verbose ] command to view details about MLD groups
configured with SSM mapping.

l Run the display mld ssm-mapping group [ ipv6-group-address ] command to view SSM
mapping rules of a specified MLD group.
----End
Example
Run the display mld interface verbose command, and you can see details about MLD interfaces.
The SSM-Mapping field in the command output shows whether the SSM mapping function is
enabled on an interface. For example:
<HUAWEI> display mld interface verbose
MLD is enabled
MLD state: up
Run the display mld group ssm-mapping verbose command, and you can see details about the
MLD groups configured with SSM mapping. For example:
<HUAWEI> display mld group ssm-mapping verbose
Ethernet1/0/0(FE80:1::101):
Total 1 MLD SSM-Mapping Group reported
Group: FF37::1
Uptime: 00:00:21
Expires: 00:03:59
Last reporter: FE80::208:A1FF:FE83:F82A
Version1-host-present-timer-expiry: off
Source list:
Source: 1::1
Uptime: 00:00:21
Source: 1::2
Uptime: 00:00:21
Source: 1::3
Uptime: 00:00:21
Run the display mld ssm-mapping group command, and you can see information about the
SSM mapping rules of a specified MLD group. For example:
<HUAWEI> display mld ssm-mapping group
MLD SSM-Mapping conversion table of VPN-Instance: public net

00001. (1::1, FF37::)
00002. (1::2, FF37::)
00003. (1::3, FF37::1)
Run the display mld ssm-mapping interface command, and you can see information about the
interfaces enabled with the SSM mapping function. For example:
<HUAWEI> display mld ssm-mapping interface
GigabitEthernet1/0/0(FE80::1)
7.5 Configuring an MLD Router-Alert Option

In this configuration task, you can configure a device to deny all the MLD packets without
Router-Alert options or send MLD packets without Router-Alert options.
Generally, a device sends a packet to the routing protocol layer for processing only if the
destination IP address of the packet is the IP address of a local interface. The destination IP
address of an MLD packet is usually a multicast address but not the address of an interface on
a multicast device and thus the MLD packet may fail to be sent to the routing protocol layer for
processing. Router-Alert options can address such a problem. MLD packets carrying Router-
Alert options need to be sent to the routing protocol layer for processing.
NOTE
For details about Router-Alert options, see RFC 2113.
Before configuring an MLD Router-Alert option, complete the following tasks:
7.5.1 Configuring a Multicast Device to Deny MLD Packets Without

This configuration task enables a device to deny all the MLD packets without Router-Alert
options.
Context
By default, the router does not check whether the received MLD packets contain Router-Alert
options, that is, the router accepts and processes all the received MLD packets.


Procedure
1. Run:
system-view

2. Run:
mld

3. Run:
require-router-alert
The multicast device is configured to accept and process only the MLD packets with
Router-Alert options and discard those without Router-Alert options.
4. Run:
commit

1. Run:
system-view

2. Run:
is displayed.
3. Run:
mld require-router-alert
The interface is configured to accept and process only the MLD packets with Router-
Alert options and discard those without Router-Alert options.
4. Run:
commit
----End
7.5.2 Configuring a Multicast Device to Send MLD Packets Without

If some MLD interfaces on the same network need to receive MLD packets without Router-
Alert options, configure the multicast device connected to the user network segment to send
MLD packets without Router-Alert options.

Context
By default, the router sends MLD packets with Router-Alert options.
Procedure
1. Run:
system-view

2. Run:
mld

3. Run:
undo send-router-alert
The device is configured to send MLD packets without Router-Alert options.

4. Run:
commit

1. Run:
system-view

2. Run:
is displayed.
3. Run:
undo mld send-router-alert
The interface is configured to send MLD packets without Router-Alert options.

4. Run:
commit

----End

After an MLD Router-Alert option is configured, check the configurations and operating status
of MLD to ensure normal running of MLD.

Prerequisite
All the MLD Router-Alert option configurations are complete.
Procedure
interface.
----End
Example
Run the display mld interface verbose command, and you can see details about MLD interfaces.
The command output shows that GE 1/0/0 denies the received packets that do not contain Router-
Alert options. For example:
MLD is enabled
MLD state: up
Require-router-alert: enabled
7.6 Configuring an MLD Querier

Configuring an MLD querier involves setting the interval for sending general query messages,
robustness variable, maximum response time of Query messages, Keepalive time of other MLD
queriers, and interval for sending MLD last-listener query messages, and configuring the MLD
prompt leave function.

CAUTION
MLD parameters; otherwise, multicast devices on the network fail to communicate with each
other.
An MLD querier is responsible for periodically sending MLD Query messages on a shared
network segment to update group memberships. You can configure parameters of an MLD
querier either globally or on an interface.

NOTE
During the configuration, ensure that the interval for sending general query messages is greater than the
maximum response time of Query messages but is smaller than the Keepalive time of other MLD queriers.
Before configuring an MLD querier, complete the following tasks:

Procedure
1. Run:
system-view

2. Run:
mld

3. Run:

4. Run:
An MLD robustness variable is set.
By default, the robustness variable of an MLD querier is 2. The greater the robustness
variable is, the longer timeout period a group membership has.

When the router starts, the router sends general query messages for the number of
robust-value times. The sending interval is 1/4 of the interval for sending MLD general
query messages.
After receiving a Done message, the router sends last-listener query messages for the
number of robust-value times. The sending interval is set by using the lastlistener-
queryinterval command.
5. Run:
max-response-time interval
The maximum response time of MLD Query messages is set.

By default, the maximum response time of MLD Query messages is 10 seconds.
6. Run:
timer other-querier-present interval
The Keepalive time of other MLD queriers is set.

The formula used to calculate the Keepalive time of other MLD queriers is: Keepalive
time of other MLD queriers = Robustness variable x Interval for sending MLD general
query messages + 1/2 x maximum response time of MLD Query messages. If the
robustness variable, the interval for sending MLD general query messages, and the
maximum response time of MLD Query messages are all of default values, the
Keepalive time of other MLD queriers is 255 seconds.
7. Run:
lastlistener-queryinterval interval
The interval for sending MLD last-listener query messages is set.

By default, the interval for sending MLD last-listener query messages is one second.
The shorter the interval is, the more sensitive the querier is.
8. Run:
commit

1. Run:
system-view

2. Run:

3. Run:
mld timer query interval

4. Run:
mld max-response-time interval
The maximum response time of MLD Query messages is set.

5. Run:
mld timer other-querier-present interval

The Keepalive time of other MLD queriers is set.

6. Run:
mld robust-count robust-value
An MLD robustness variable is set.

7. Run:
mld lastlistener-queryinterval interval
The interval for sending MLD last-listener query messages is set.

8. Run:
mld prompt-leave [ group-policy { basic-acl6-number | acl6-name acl6-
name } ]
The MLD prompt leave function is configured on the interface.
By default, MLD-enabled interfaces send last-listener query messages after receiving

Done messages for a specific multicast group from hosts. If the MLD prompt leave
function is enabled, the interfaces directly delete the records of the multicast group
without sending last-listener query messages.
9. Run:
commit
----End

Run the display mld interface verbose command to view the configurations and operating
status of MLD on an interface.
MLD is enabled
MLD state: up

7.7 Maintaining MLD

Maintaining MLD involves resetting MLD group information, monitoring MLD operating
status, and debugging MLD.
7.7.1 Clearing MLD Group Information

After you confirm to clear MLD group information, use the reset command in the user view.
Context
CAUTION
The reset mld group or reset mld group ssm-mapping command clears information about the
MLD groups that an interface dynamically joins, which may cause receivers to fail to receive
multicast data normally. Exercise caution when running this command.
Procedure
l To clear information about the MLD groups (excluding the MLDv1 groups in the SSM
group address range) that an interface dynamically joins, run the following commands in
the user view:
reset mld group all
reset mld group interface interface-type interface-number { all | ipv6-group-
address [ ipv6-group-mask-length ] [ ipv6-source-address [ ipv6-source-mask-
length ] ] }
l To clear information about the MLDv1 groups in the SSM group address range, run the
following commands in the user view:
reset mld group ssm-mapping all
reset mld group ssm-mapping interface interface-type interface-number { all | ipv6-
group-address [ ipv6-group-mask-length ] }
l To clear information about the MLD groups that an interface statically joins, run the undo
mld static-group { all | ipv6-group-address [ source ipv6-source-address ] } command in
the user view.
----End
7.7.2 Monitoring the Operating Status of MLD

You can monitor the operating status of MLD by viewing MLD group information, SSM
mapping information, MLD-enabled interface information, and MLD routing table information.
Context
In routine maintenance, you can run the following commands in any view to view the operating
status of MLD.

Procedure
number ] * [ static ] [ verbose ] command to view MLD group information on an interface.
number ] * ssm-mapping [ verbose ] command to view information about the MLD groups
configured with SSM mapping.
l Run the display mld interface [ interface-type interface-number ] [ verbose ] command
to view the configurations and operating status of MLD on an interface.
l Run the display mld ssm-mapping group [ ipv6-group-address ] command to view SSM
mapping rules of a specified MLD group.
----End

Configuration examples show you how to configure basic MLD functions and how to configure
MLD SSM mapping.
7.8.1 Example for Configuring Basic MLD Functions

After basic MLD functions are configured on an IPv6 multicast network, user hosts can steadily
receive multicast data from multicast sources.
CAUTION
slot number.
As shown in Figure 7-3, IPv6 multicast services are deployed on the ISP network. An IGP has
been deployed to ensure that IPv6 unicast routes are available. Hosts on this network want to
receive VOD information with the IPv6 multicast service. For example, Host A and Host B want
to join multicast group FF13::101 to steadily receive popular programs.

Figure 7-3 Networking diagram of configuring basic MLD functions
Ethernet
HostA
PIM network RouterA Receiver
N1
GE1/0/0
POS2/0/0
HostB
POS2/0/1
RouterB Leaf network
POS2/0/2 GE1/0/0
HostC
POS2/0/3 N2
RouterC
GE1/0/0 HostD
POS2/0/0
Ethernet

Router A POS 2/0/0 2001::1/64 Router D POS 1/0/0 2000::1/64
GE 1/0/0 3001::10/64 POS 2/0/1 2001::2/64
Router B POS 2/0/0 2002::1/64 POS 2/0/2 2002::2/64
GE 1/0/0 3002::10/64 POS 2/0/3 2003::2/64
Router C POS 2/0/0 2003::1/64
GE 1/0/0 3003::10/64
Precautions
When configuring basic MLD functions, note the following points:
l IPv6 PIM-SM and then MLD must be enabled on the interfaces connected to hosts.
l Interfaces connected to the same user network segment must use the same MLD version.
On an IPv6 PIM-SM network where MLD is enabled on the interface connected to user hosts,
if an interface needs to forward the data for an IPv6 multicast group for a long time, the interface
can be configured to statically join the IPv6 multicast group. The configuration roadmap is as
follows:
1. Configure IPv6 addresses for interfaces on each router and configure a unicast routing
protocol.
2. Enable IPv6 multicast routing on all routers providing IPv6 multicast services.
3. Enable IPv6 PIM-SM on all interfaces of the multicast routers.
4. Enable MLD on the interfaces connected to hosts.
5. Configure GE 1/0/0 on Router A to statically join MLD group FF13::101 to steadily receive
multicast data.

Data Preparation
l Version numbers of MLD run on routers and user hosts

l Address of the MLD group that interfaces statically joins
Procedure
Step 1 Configure IPv6 addresses for interfaces on each router and configure a unicast routing protocol.
Step 2 Enable IPv6 multicast on each router and IPv6 PIM-SM on each interface of the routers.
[~RouterD] multicast ipv6 routing-enable
[~RouterD-Pos1/0/0] pim ipv6 sm

# Configure a dynamic RP on Router D.
[~RouterD] pim-ipv6
[~RouterD-pim6] c-bsr pos 1/0/0
[~RouterD-pim6] c-rp pos 1/0/0
[~RouterD-pim6] commit
[~RouterD-pim6] quit
Step 4 Enable MLD on the interfaces connected to hosts.

# Configurations on Routers B and C are similar to those on Router A and therefore their
[~RouterA-GigabitEthernet1/0/0] mld enable
Step 5 Configure GE 1/0/0 on the Router A to statically join MLD group FF13::101.
[~RouterA-GigabitEthernet1/0/0] mld static-group ff13::101

# Run the display mld interface command to view brief MLD information on the interfaces of
the router. For example, MLD information on GE 1/0/0 of Router B is as follows:
<RouterB> display mld interface

GigabitEthernet1/0/0(FE80::200:5EFF:FE66:5100):
MLD is enabled
MLD state: up
Querier for MLD: FE80::200:5EFF:FE66:5100 (this router)
The command output shows that Router B is a querier. This is because GE 1/0/0 of Router B
has the lowest IPv6 address among the interfaces connected to the user network segment.
# Run the display pim ipv6 routing-table command on Router A to check whether GE 1/0/0
has joined MLD group FF13::101 statically. If a (*, FF13::101) entry is generated on Router A,
the downstream interface is GE 1/0/0, and the protocol type is static, GE 1/0/0 has joined MLD
group 225.1.1.1 statically. The command output as follows:
<RouterA> display pim ipv6 routing-table
(*, FF13::101)
RP: 2000::1
UpTime: 00:12:17
Upstream neighbor: 2001::1
RPF prime neighbor: 2001::1
Protocol: mld, UpTime: 00:12:17, Expires: -
----End
Configuration Files
#
sysname RouterA
#
#
isis 1
ipv6 enable topology standard
network-entity 10.0000.0000.0001.00
#
undo shutdown
ipv6 enable
ipv6 address 3001::10/64
pim ipv6 sm
mld enable
mld static-group ff13::101
isis ipv6 enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
mld enable
isis ipv6 enable 1
#
return


#
sysname RouterB
#
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ipv6 enable
pim ipv6 sm
mld enable
isis ipv6 enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
return

#
sysname RouterC
#
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ipv6 enable
pim ipv6 sm
mld enable
isis ipv6 enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
return

#
sysname RouterD
#
#
isis 1
network-entity 10.0000.0000.0004.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp


pim ipv6 sm
isis ipv6 enable 1
#
interface Pos2/0/1
undo shutdown
link-protocol ppp
pim ipv6 sm
isis ipv6 enable 1
#
interface Pos2/0/2
undo shutdown
link-protocol ppp
pim ipv6 sm
isis ipv6 enable 1
#
interface Pos2/0/3
undo shutdown
link-protocol ppp
pim ipv6 sm
isis ipv6 enable 1
#
return
7.8.2 Example for Configuring MLD SSM Mapping

If user hosts on an IPv6 network run only MLDv1 and cannot be upgraded to MLDv2, SSM
mapping is required to implement version compatibility between a multicast device (running a
higher MLD version) and user hosts (running lower MLD versions) and enable the multicast
device to provide SSM services for the user hosts. The user hosts can then receive IPv6 multicast
data from a specified source.
CAUTION
slot number.
On the IPv6 multicast network shown in Figure 7-4, PIM-SM is run and the SSM mode is
configured to provide IPv6 multicast services. MLDv2 is run on the interface connecting the
router to the receiver and MLDv1 is run on the receiver. The MLD version on the receiver is
unable to be upgraded to MLDv2.
The SSM group address range is set to FF31::/32 on the current network and Sources 1, 2, and
3 all send IPv6 multicast data to multicast groups in this range. The receiver, however, wants to
receive IPv6 multicast data only from Sources 1 and 3.

Figure 7-4 Networking diagram for configuring MLD SSM mapping

Source2
RouterB RouterC Source3
GE1/0/0 GE3/0/0 GE3/0/0 GE1/0/0
GE2/0/0 GE2/0/0
Leaf network Leaf network
PIM-SM
Source1 DSLAM
GE2/0/0 GE2/0/0
GE1/0/0 GE1/0/0
GE3/0/0 GE3/0/0
RouterA RouterD
Leaf network
Receiver

Router A GE 1/0/0 2001::2/64 Router C GE 1/0/0 2003::2/64
GE 2/0/0 3001::1/64 GE 2/0/0 3004::1/64
GE 3/0/0 3003::1/64 GE 3/0/0 3002::2/64
Router B GE 1/0/0 2002::2/64 Router D GE 1/0/0 2004::2/64
GE 2/0/0 3001::2/64 GE 2/0/0 3004::2/64
GE 3/0/0 3002::1/64 GE 3/0/0 3003::2/64
Precautions
When configuring MLD SSM mapping, note the following points:
l The SSM group address ranges set on all routers in the IPv6 PIM-SM domain must be
consistent.
l The SSM source/group address mapping entries configured on the interface take effect only
after SSM mapping is enabled on the interface.
SSM mapping is configured on the router directly connected to user hosts to enable the router
to be compatible with hosts running a lower protocol version, thus providing SSM services. The
configuration roadmap is as follows:
1. Configure IPv6 addresses for interfaces on each router and configure a unicast routing
protocol.
3. Enable IPv6 PIM-SM on all interfaces of the multicast routers.
4. Enable MLD and SSM mapping on the interface connecting the router to the receiver.
5. Set SSM group address ranges on all routers in the IPv6 PIM-SM domain.

6. Configure SSM mapping rules on the router connected to the receiver.
Data Preparation
l IPv6 addresses of Sources 1 and 3
Procedure
Step 1 Configure IPv6 addresses for interfaces on each router and configure a unicast routing protocol.
[~RouterD] multicast ipv6 routing-enable
[~RouterD-GigabitEthernet1/0/0] pim ipv6 sm
Step 3 Enable MLD and SSM mapping on the interface connecting the router to the receiver.
# Enable MLD and SSM mapping on GE 1/0/0 of Router D.
[~RouterD-GigabitEthernet1/0/0] mld enable
[~RouterD-GigabitEthernet1/0/0] mld version 2
[~RouterD-GigabitEthernet1/0/0] mld ssm-mapping enable

# Set SSM group address ranges to FF31::/32 on all routers in the IPv6 PIM-SM domain. The
configurations of Routers B, C, and D are similar to those on Router A. Their configuration
details are not provided here.
[~RouterA] acl ipv6 number 2000
[~RouterA-acl6-basic-2000] rule permit source ff31::/32
[~RouterA] pim-ipv6
[~RouterA-pim6] ssm-policy 2000
[~RouterA-pim6] commit
[~RouterA-pim6] quit
Step 5 Configure SSM mapping rules on the router connected to the receiver.
# On Router D, map the multicast groups in the range of FF31::/32 to Sources 1 and 3.
[~RouterD] mld
[~RouterD-mld] ssm-mapping ff31:: 32 2001::1
[~RouterD-mld] ssm-mapping ff31:: 32 2003::1
[~RouterD-mld] commit

[~RouterD-mld] quit

# View information about SSM mapping rules on Router D.
<RouterD> display mld ssm-mapping group
MLD SSM-Mapping conversion table of VPN-Instance: public net
00001. (2001::1, FF31::)
00002. (2003::1, FF31::)
# The command output shows that the receiver joins group FF31::1. Then run the display mld
group ssm-mapping command to view source/group information on router D. The command
output is as follows:
<RouterD> display mld group ssm-mapping
MLD SSM mapping interface group report information of VPN-Instance: public net
GigabitEthernet1/0/0 (2004::2):
FF31::1 2004::1 00:01:44 00:00:26
<RouterD> display mld group ssm-mapping verbose
Total entry on this router: 1
GigabitEthernet1/0/0(FE80::DD:84):
Group: FF31::1
Uptime: 00:00:13
Expires: 00:04:07
Last reporter: FE80::10
Group mode: exclude
# Run the display pim ipv6 routing-table command to view information about the IPv6 PIM-
SM routing table on Router D. The command output is as follows:
<RouterD> display pim ipv6 routing-table
(2001::1, FF31::1)
UpTime: 00:11:25
Protocol: mld, UpTime: 00:11:25, Expires:-
(2003::1, FF31::1)
UpTime: 00:11:25
Protocol: mld, UpTime: 00:11:25, Expires:-
----End

Configuration Files
#
sysname RouterA
#
#
acl ipv6 number 2000
rule permit source ff31::/32
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
pim-ipv6
ssm-policy 2000
#
return

#
sysname RouterB
#
#
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
ipv6 address 3001::2
pim ipv6 sm
isis ipv6 enable 1
#

undo shutdown
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
pim-ipv6
ssm-policy 2000
#
return
#
sysname RouterC
#
#
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
pim-ipv6
ssm-policy 2000
#
return
#
sysname RouterD
#
#
#
isis 1
network-entity 10.0000.0000.0004.00
#
undo shutdown
ipv6 enable
pim ipv6 sm
mld enable
mld version 2

mld ssm-mapping enable

isis ipv6 enable 1
#
undo shutdown
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
undo shutdown
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
mld
ssm-mapping ff31:: 32 2001::1
ssm-mapping ff31:: 32 2003::1
#
pim-ipv6
ssm-policy 2000
#
return

Configuration Guide - IP Multicast 8 IPv6 PIM Configuration
8 IPv6 PIM Configuration
About This Chapter
IPv6 PIM is used to advertise IPv6 multicast routes and forward data in an AS.
8.1 IPv6 PIM Overview

IPv6 Protocol Independent Multicast (PIM) is an intra-domain multicast routing protocol. It uses
existing IPv6 unicast routing information to perform a Reverse Path Forwarding (RPF) check
on IPv6 multicast packets and to create IPv6 multicast routing entries. PIM can also respond
dynamically to network topology changes and maintain IPv6 multicast forwarding tables.
8.2 IPv6 PIM Features Supported by the NE5000E
The NE5000E supports PIM-SM and PIM-SSM. Default parameter values allow a device to
function properly. Users can improve security on IPv6 PIM networks by adjusting control
parameters for neighbor relationships and for multicast forwarding, and by configuring various
filtering policies.
8.3 Configuring IPv6 PIM-SM
Any sender on a PIM-SM network can be a multicast source. Therefore, receivers do not know
the location of the multicast source on the PIM-SM network in advance. An RP is the forwarding
core on a PIM-SM network. It collects information about group members and multicast sources.
There are static RPs and BSR RPs.
8.4 Configuring a BSR Boundary (IPv6)
Before configuring IPv6 PIM-SM inter-domain multicast, configure BSR boundaries to divide
a multicast network into PIM-SM domains. Each BSR serves only the local PIM-SM domain.
The routers outside the BSR boundary of a PIM-SM domain do not take part in BSR messages
forwarding in the PIM-SM domain.
8.5 Adjusting Dynamic RP Parameters (IPv6)
When a dynamic RP is used on a network, parameters of C-RPs and C-BSRs on the network
can be adjusted as needed.
8.6 Configuring IPv6 PIM-SSM
PIM-SSM enables a user to specify a multicast source that will send data to a desired group.
PIM-SSM is implemented based on some PIM-SM technologies. In PIM-SSM, no RP needs to
be maintained and a dedicated multicast forwarding path is set up between a receiver and a
specified multicast source.

8.7 Adjusting Other IPv6 PIM Parameters

You can adjust the control parameters for maintaining neighbor relationships, DR parameters,
and control parameters for forwarding as needed.
8.8 Maintaining IPv6 PIM
Maintaining IPv6 PIM includes resetting statistics about IPv6 PIM control messages, monitoring
the operating status of IPv6 PIM, and debugging IPv6 PIM.
This section provides several IPv6 PIM configuration examples showing how to build up a basic
IPv6 PIM network and how to configure basic IPv6 PIM functions.

8.1 IPv6 PIM Overview

IPv6 Protocol Independent Multicast (PIM) is an intra-domain multicast routing protocol. It uses
existing IPv6 unicast routing information to perform a Reverse Path Forwarding (RPF) check
on IPv6 multicast packets and to create IPv6 multicast routing entries. PIM can also respond
dynamically to network topology changes and maintain IPv6 multicast forwarding tables.
IPv6 PIM is independent of any specific unicast routing protocol. It can leverage whichever
unicast routing protocols are used to populate the unicast routing table. These unicast routing
protocols include IPv6 static routes, Routing Information Protocol next generation (RIPng),
Open Shortest Path First Version 3 (OSPFv3), Intermediate System-Intermediate System for
IPv6 (IS-ISv6), or Border Gateway Protocol (BGP4+). It uses unicast routing information to
implement the multicast forwarding function.
PIM forwards multicast packets by means of the RPF mechanism. The RPF mechanism uses
existing unicast routing information to set up a multicast distribution tree (MDT) on a network.
When a multicast packet reaches the router, the router first performs an RPF check on it.
l If the multicast packet passes the RPF check, the router creates a multicast routing entry,
and then forwards the multicast packet based on the entry.
l If the multicast packet fails the RPF check, the router discards it.
NOTE
Information in this chapter concerns PIM configurations on an IPv6 network only. Unless otherwise noted,
the term PIM refers to IPv6 PIM.
PIM Mode
PIM has three modes: Protocol Independent Multicast-Sparse Mode (PIM-SM), Protocol
Independent Multicast Source-Specific Multicast (PIM-SSM), and Protocol Independent
Multicast-Dense Mode (PIM-DM). PIM-SM and PIM-DM use group addresses in the ASM
group address range, whereas PIM-SSM uses group addresses in the SSM group address range.
l PIM-SM
PIM-SM is for use on a large-scale network where multicast group members are sparsely
distributed. Working mechanisms of PIM-SM include neighbor discovery, Assert,
Designated Router (DR) election, Rendezvous Point (RP) discovery, Join, Prune, Register,
and Shortest Path Tree (SPT) switchover.
l PIM-SSM
Users on a PIM-SSM network know the location of a multicast source in advance. When
joining a multicast group, a user can specify the source that sends data to the multicast
group. PIM-SSM makes use of some PIM-SM technologies. PIM-SSM does not need to
maintain an RP, construct an RP Tree (RPT), or register a multicast source. In PIM-SSM,
an SPT can be built directly between the source's DR and the receiver's DR.
l PIM-DM
PIM-DM is for use on a small-scale network where multicast group members are densely
distributed. Working mechanisms of PIM-DM include neighbor discovery, flooding,
Prune, Graft, Assert, and State-Refresh.
NOTE
Currently, the NE5000E supports IPv6 PIM-SM and PIM-SSM.

8.2 IPv6 PIM Features Supported by the NE5000E

The NE5000E supports PIM-SM and PIM-SSM. Default parameter values allow a device to
function properly. Users can improve security on IPv6 PIM networks by adjusting control
parameters for neighbor relationships and for multicast forwarding, and by configuring various
filtering policies.
PIM-SM
l Embedded-RP
An embedded RP embeds its address inside an IPv6 group address. After obtaining an IPv6
group address, the router can obtain the RP address to which the IPv6 group address
corresponds. Embedded RPs are preferred to RPs discovered by other RP election
mechanisms.
l Static RP
If a static RP is used in a PIM-SM domain, the static RP configurations on all routers in
the PIM-SM domain must be the same. If a BSR RP and a static RP exist in a domain, the
BSR RP takes precedence over the static RP. You can configure the static RP to have
priority over the BSR RP.
l BSR RP
After Candidate RPs (C-RPs) and Candidate BSRs (C-BSRs) are configured on several
routers in a PIM-SM domain, a BSR will be elected from the C-BSRs by using defined
rules. This BSR collects C-RP information to elect an RP from the C-RPs.
l BSR boundary
Configuring a BSR boundary on an interface of the router limits the transmission of BSR
messages, thus dividing a network into PIM-SM domains.
l Adjusting C-RP parameters and C-BSR parameters
You can adjust the following C-RP parameters:
C-RP priority level used for an RP election
Interval at which a C-RP sends Advertisement messages
Period during which a BSR keeps an Advertisement message received from a C-RP
Ranges defined by an IPv6 ACL of valid C-RP addresses and groups that these C-RPs
serve
You can adjust the following C-BSR parameters:
Hash mask length of a C-BSR, used for RP calculations
C-BSR priority level used for a BSR election
Interval at which a C-BSR sends Bootstrap messages
Period during which a C-BSR keeps Bootstrap messages received from a BSR
Range of valid BSR addresses defined by an IPv6 ACL
l Adjusting control parameters for source registration
You can adjust the following control parameters for source registration:
Rules used by an IPv6 ACL for filtering Register messages
Method for calculating the checksum of a Register message

Period during which source registration is suppressed

Interval at which null Register messages are sent
l Configuring the conditions that trigger an SPT switchover
You can configure the conditions that trigger an SPT switchover, and adjust the interval
for detecting multicast data forwarding rates.
PIM-SSM
PIM-SSM allows hosts to specify a multicast source from which they expect to receive multicast
data when they join multicast groups. You can set a range of SSM group addresses as needed.
Source Address-based Filtering

You can use an IPv6 ACL to specify a range of valid multicast source addresses.
Adjusting Control Parameters for Maintaining Neighbor Relationships

You can adjust the following control parameters for maintaining PIM neighbor relationships:
l Interval for sending Hello messages
l Period for maintaining the status of a neighbor as reachable.
l Whether or not to accept Hello messages containing the generation ID option
l DR election priority level
l Whether or not to enable the neighbor filtering function
Adjusting Control Parameters for Forwarding

You can adjust the following control parameters for forwarding:
l Interval for sending Join messages
l Period for maintaining the forwarding status of a downstream interface
l Interval for overriding a prune action
l Period for maintaining the Assert status of an interface
l Rules for filtering Join/Prune messages
PIM NSR
PIM supports non-stop routing (NSR). After this function is enabled, if the control plane of a
device fails and a standby control plane is available, the device immediately implements active
standby switchover and restores services. The control planes of the device's neighbors do not
sense this active/standby switchover. During the active/standby switchover of the control planes,
the device can process new services, such as new Join messages.
For details about NSR, refer to the HUAWEI NetEngine5000E Feature Description -
Reliability.
PIM in Distributed Mode

The PIM module has a core component responsible for calculating and maintaining routing
entries. One main control board can start multiple core components. The core component
considers all multicast group addresses as a set and divides the set into several subsets based on

the hash result of multicast group addresses. Each core component bears one or more subsets.
The system automatically allocates the services to be carried by each subset. By distributing
multicast services among these subsets, CPU and memory usage are reduced.
8.3 Configuring IPv6 PIM-SM

Any sender on a PIM-SM network can be a multicast source. Therefore, receivers do not know
the location of the multicast source on the PIM-SM network in advance. An RP is the forwarding
core on a PIM-SM network. It collects information about group members and multicast sources.
There are static RPs and BSR RPs.
PIM-SM is for use on large-scale networks where group members are sparsely distributed and
receivers do not need to specify a multicast source when joining a multicast group. An RP is the
forwarding core on a PIM-SM network. It collects information about group members and
multicast sources.
l After creating a (*, G) entry for a new IGMP member relationship, the receiver's DR sends
a Join/Prune message to the RP.
l When a multicast source starts to send data to a group, the source's DR unicasts a Register
message to the RP. The RP de-encapsulates the Register message and forwards the data to
other multicast members along the RPT.
l RP switches traffic from the RPT to the SPT, then the RP sends a Register-Stop message
to the source's DR.
On an IPv6 network, PIM-SM supports the following types of RPs:
l Embedded-RP
By default, an embedded-RP is started. The range of groups served by an embedded-RP is
limited. To avoid inconsistent RP election results, PIM-SM stipulates that an embedded
RP is preferred to RPs discovered by other RP election mechanisms.
l Static RP
A static RP needs to be configured on every router in a PIM-SM domain. A static RP is for
use on small-scale PIM networks with stable topology. On a large-scale PIM network,
configuring a static RP is complex. A static RP is usually used as a backup for a dynamic
RP. This enhances the robustness and increases the operation and management capabilities
of multicast networks.
l BSR RP
After C-RPs and C-BSRs are configured on several routers in a PIM-SM domain, an RP
can be elected among the C-RPs. Each router in the PIM-SM domain knows the location
of the RP.
It is possible for a multicast group to be within the service range of an embedded-RP, a BSR
RP, and a static RP simultaneously. The default sequence used by routers to select an RP for
such groups is embedded-RP > BSR RP > static RP.
Compared with a scheme in which all groups correspond to a single RP, a scheme in which
different multicast groups correspond to different RPs reduces the load on individual RPs,
making the network more robust.

Before configuring IPv6 PIM-SM, complete the following task:
l Configure an IPv6 unicast routing protocol to ensure that IPv6 unicast routes are reachable
on the network
Figure 8-1 Flowchart for configuring IPv6 PIM-SM

Use a Embedded-RP Use a static RP Use a BSR RP
Enable IPv6 Enable IPv6 Enable IPv6
multicast routing multicast routing multicast routing
Enable IPv6 PIM-SM Enable IPv6 PIM-SM Enable IPv6 PIM-SM
Configure a embedded-
Configure a static RP Configure a BSR RP
RP
Configure a static RP Configure a BSR RP Configure a static RP
Set a multicast source Set a multicast source

Configure a BSR RP
address range address range
Set a multicast source Adjust source registration Adjust source registration

address range parameters parameters
Adjust source registration Configure SPT switchover Configure SPT switchover

parameters conditions conditions
Mandatory
Configure SPT switchover procedure
conditions
Optional
procedure

router.
Procedure
Step 1 Run:
system-view

Step 2 Run:
CAUTION
Step 3 Run:
commit
----End

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
pim ipv6 sm
CAUTION
the interface.
Step 4 Run:
commit
----End

8.3.3 Configuring an Embedded-RP

By default, the embedded-RP function is enabled. You can use related commands to change the
range of IPv6 multicast groups that an embedded RP serves or disable the embedded-RP
function.
Context
The embedded-RP function can be applied in an IPv6 PIM-SM domain and among PIM-SM
domains. It solves the problem that IPv6 PIM-SM domains cannot learn RP information from
each other because MSDP does not support IPv6 networks.
To avoid inconsistent results of RP elections, PIM-SM defines that an RP obtained by using the
embedded-RP function takes precedence over other RPs elected by using other mechanisms.
The range of IPv6 groups that an embedded RP serves is FF70::/12. You can change the range
of IPv6 multicast groups that an embedded RP serves.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
The IPv6 PIM view is displayed.
Step 3 Run:
embedded-rp [ basic-acl6-number | acl6-name acl6-name ]
The range of IPv6 groups that an embedded-RP serves is set.
If the group range defined by an IPv6 ACL is greater than the default range of groups that an
embedded RP serves, the embedded-RP is valid for the intersection part of the two address
ranges.
The same range of groups that an embedded-RP serves must be set on all routers in an IPv6
PIM-SM domain.
NOTE
You can run the undo embedded-rp command to disable the embedded-RP function.
Step 4 Run:
commit
----End
8.3.4 Configuring a Static RP

Configuring a static RP means manually specifying the location of an RP and range of groups
that the RP serves. The same static RP must be configured on all routers in an IPv6 PIM-SM
domain.

Context
The routers that are not configured with static RPs do not forward multicast packets in the local
IPv6 PIM-SM domain.
If an IPv6 PIM-SM network is divided into multiple IPv6 PIM-SM domains and each IPv6 PIM-
SM domain uses a static RP, the same static RP must be configured on all routers in the IPv6
PIM-SM domain to demarcate the range of the domain.
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim-ipv6

Step 3 Run:
static-rp rp-address [ basic-acl6-number | acl6-name acl6-name ] [ preferred ]
A static RP is configured.
Multiple static RPs can be configured for the router by using this command repeatedly, but an
IPv6 ACL cannot correspond to multiple static RPs. If no IPv6 ACL is referenced, only one
static RP can be configured.
l rp-address specifies the address of a static RP.
l basic-acl6-number | acl6-name acl6-name specifies the number of a basic IPv6 ACL. This
basic IPv6 ACL defines the range of IPv6 groups served by a static RP. When the IPv6
multicast group ranges to which multiple static RPs correspond overlap, the static RP with
the highest IPv6 address serves IPv6 multicast groups.
l preferred indicates that a static RP is preferred. If a BSR RP and a static RP exist on a
network, after preferred is set, the routers on the network prefer the static RP. Otherwise,
the routers prefer the BSR RP.
Step 4 Run:
commit
----End
8.3.5 Configuring a BSR RP

After several routers are configured as C-BSRs and C-RPs, a BSR is elected among the C-BSRs.
The BSR collects information about the C-RPs and summarizes it into an RP-set. Then, the BSR
encapsulates the RP-set in Bootstrap messages, and sends the messages to all devices in the PIM
domain. The devices elect an RP based on certain rules.
Context
When an IPv6 PIM-SM network is divided into multiple IPv6 PIM-SM domains and a dynamic
RP is used, perform the task of Configuring a BSR Boundary on the interface of the router at

the edge of each IPv6 PIM-SM domain to demarcate the range of the domain, and then configure
C-BSRs and C-RPs in each IPv6 PIM-SM domain.
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim-ipv6

Step 3 Run:
c-bsr ipv6-address [ hash-length ]
A C-BSR is configured.
l ipv6-address specifies the IPv6 address of the interface where a C-BSR resides. The interface
must be enabled with IPv6 PIM-SM.
l hash-length specifies the hash mask length.
Based on the group address G, C-RP address, and the value of hash-length, routers use hash
functions to calculate the C-RPs that have the same priority and want to serve G, and then
compare the calculation results. The C-RP that has the greatest calculated value acts as the
RP that serves G.
Step 4 Run:
c-rp ipv6-address [ group-policy { basic-acl6-number | acl6-name acl6-name } |
priority priority | holdtime hold-interval | advertisement-interval adv-interval ]
*
A C-RP is configured.
l ipv6-address specifies the IPv6 address of the interface where a C-RP resides. The interface
must be enabled with IPv6 PIM-SM.
l group-policy { basic-acl6-number | acl6-name acl6-name } indicates that a C-RP serves
only IPv6 multicast groups within the IPv6 multicast group range defined by a specified IPv6
ACL. By default, a C-RP serves all IPv6 multicast groups.
l priority priority specifies the priority of a C-RP. The greater the priority value, the lower
the priority.
An RP is elected based on the following rules:
The C-RP that has the highest priority wins.
In case of the same priority, hash functions are operated. The C-RP that has the greatest
calculated value wins.
In the case of the same calculated value, the C-RP that has the highest IPv6 address wins.
l holdtime hold-interval: specifies the timeout period during which the BSR waits to receive
Advertisement message from a C-RP.
l advertisement-interval adv-interval specifies the interval at which a C-RP sends
Advertisement messages.
Step 5 Run:
commit

----End
8.3.6 (Optional) Limiting the Range of Multicast Source Addresses

After being configured with an IPv6 source address-based filtering policy by using an IPv6 ACL,
the IPv6 PIM router forwards only the multicast packets with source addresses or source/group
addresses being in the range defined by the IPv6 ACL.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
source-policy { acl6-number | acl6-name acl6-name }
The range of multicast source addresses is limited.
l If a basic IPv6 ACL is used, only the multicast data packets with source addresses being in
the range permitted by the IPv6 ACL can be forwarded.
l If an advanced IPv6 ACL is used, only the multicast data packets with source addresses and
group addresses being in the ranges permitted by the IPv6 ACL can be forwarded.
l If the specified IPv6 ACL does not exist, no multicast packets can be forwarded.
NOTE
The source-policy command cannot be used to filter static (S, G) entries.
Step 4 Run:
commit
----End
8.3.7 (Optional) Adjusting Control Parameters for Source

Registration
A new multicast source must register with an RP. The policy for filtering Register messages is
set on C-RPs, and the period for keeping the register suppression state and the interval for sending
null Register messages are set on the source's DR.
Context
On an IPv6 PIM-SM network, the source's DR encapsulates received IPv6 multicast data in a
Register message and then unicasts the Register message to the RP. After receiving the Register
message, the RP decapsulates it, and then forwards the IPv6 multicast data to receivers along

the RPT. To avoid attacks of invalid Register messages, the RP accepts or denies the Register
messages matching the configured filtering policy.
After the RP completes the SPT switchover, the IPv6 multicast data reaches the RP along the
source tress in the multicast mode. Then, the RP sends a Register-Stop message to the source's
DR. After receiving the message, the source's DR stops sending Register messages and enters
the suppression state. In the register suppression period, the DR periodically sends Probe
messages (null Register messages) to notify the RP that the multicast source is still in the active
state. After the register suppression period expires, the DR resends the Register messages
carrying multicast data.
Default parameter values allow the router to function properly. The NE5000E allows users to
adjust related parameters as required.
NOTE
If there is no special requirement, default values are recommended.
Procedure
l Control the receiving of Register messages on a C-RP.
1. Run:
system-view

2. Run: pim-ipv6 The IPv6 PIM view is displayed.
3. Run:
register-policy { advanced-acl6-number | acl6-name acl6-name }
The policy for filtering Register messages is configured.

If the (S, G) information contained in a Register message is denied by an IPv6
ACL or no action is defined in the IPv6 ACL for processing the Register message
containing such (S, G) information, the RP discards this Register message and the
relevant multicast source cannot be registered with the RP.
If the specified IPv6 ACL does not exist, the RP denies all Register messages, and
no multicast source can register with the RP.
4. Run:
commit

l Suppress multicast source registration on the source's DR.
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:
register-suppression-timeout interval
The timeout period during which the source's DR keeps the register suppression state
is set.

By default, the source's DR keeps the register suppression state for 60s.
If the value of interval is small, the RP frequently receives burst multicast data.
If the value of interval is large, when an (S, G) entry on the RP times out, the delay
during which new receivers join a multicast group is prolonged.
4. Run:
probe-interval interval
The interval for sending Probe messages is set.

By default, the source's DR sends Probe messages to the RP at an interval of 5s.
5. Run:
commit

----End
8.3.8 (Optional) Configuring SPT Switchover Conditions

PIM-SM enables an RP or a receiver's DR to trigger an SPT switchover when the rate of IPv6
multicast packets is high. The SPT switchover conditions and the interval for checking the rate
at which IPv6 multicast data is forwarded can be configured on the receiver's DR.
Context
During the forwarding of IPv6 multicast packets in a PIM-SM domain, only one RPT is set for
each multicast group. All multicast sources encapsulate multicast data in Register messages, and
then unicast the Register messages to the RP. After receiving the Register messages, the RP
decapsulates them and then forwards multicast data along the RPT to group members.
Forwarding IPv6 multicast data by using an RPT has the following disadvantages:
l The source's DR and the RP need to frequently encapsulate and decapsulate packets.
l The forwarding path may not be the shortest path from the source to receivers.
l Heavy IPv6 multicast traffic increases the load of the RP, which easily causes a fault.
The solutions to the preceding disadvantages are as follows:
l SPT switchover triggered by the RP
The RP sends a Join message to the source to create an IPv6 multicast route along the
shortest path from the source's DR to the RP to build an MDT. Then, subsequent packets
are forwarded along the MDT.
l SPT switchover triggered by the receiver's DR
The receiver's DR checks the forwarding rate of IPv6 multicast data. If the receiver's DR
finds that the rate exceeds the threshold, it triggers the SPT switchover immediately. The
receiver's DR sends a Join message to the source to set up an IPv6 multicast route along
the shortest path from the source's DR to the receiver's DR. Subsequent IPv6 multicast
packets are forwarded along the path.
By default, the RP triggers the SPT switchover immediately after receiving the first Register
message, and the receiver's DR triggers the SPT switchover immediately after receiving the first
IPv6 multicast data packet. Default parameter values allow the router to function properly. The
NE5000E allows users to adjust related SPT switchover parameters as needed.

NOTE
If there is no special requirement, default values are recommended.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
spt-switch-threshold { traffic-rate | infinity } [ group-policy { basic-acl6-
number |acl6-name acl6-name } [ order order-value ] ]
SPT switchover conditions are configured.
NOTE
This command takes effect on all routers that may become the receiver's DR, but does not take effect on
the RP.
l traffic-rate specifies the threshold for the rate of IPv6 multicast data. When the rate of IPv6
multicast data exceeds the threshold, the receiver's DR triggers the SPT switchover.
NOTE
The configuration in Step 4 makes sense only after traffic-rate is set.

l infinity indicates that the receiver's DR never triggers the SPT switchover. IPv6 multicast
data can be transmitted to receivers only along the RPT.
l group-policy { basic-acl6-number | acl6-name acl6-name } is used to set the range of
multicast groups to which the threshold is applied. By default, the threshold is applicable to
all multicast groups.
l order order-value is used to adjust the order of the IPv6 ACLs in the group-policy list. If a
group matches multiple IPv6 ACLs, the threshold is selected in the order specified by order-
value.

timer spt-switch interval
The interval at which the receiver's DR checks the rate for forwarding IPv6 multicast data is set.
Step 5 Run:
commit
----End

After IPv6 PIM-SM is configured successfully, you can use related commands to check whether
the BSR, RP, PIM interface, PIM neighbor, and PIM routing table are correctly configured.

Prerequisite
The IPv6 PIM-SM configurations are complete.
Procedure
l Run the display pim ipv6 bsr-info command to check information about the BSR in an
IPv6 PIM-SM domain.
l Run the display pim ipv6 interface [ interface-type interface-number ] [ verbose ]
command to check information about IPv6 PIM interfaces.
l Run the display pim ipv6 neighbor [ ipv6-link-local-address | interface interface-type
interface-number | verbose ] * command to check information about IPv6 PIM neighbors.
l Run the display pim ipv6 routing-table [ group-address [ mask { group-mask-length |
group-mask } ] ] [ source-address [ mask { source-mask-length | source-mask } ] ]
[ outgoing-interface include { interface-type interface-number | register | none } ]
[ fsm ] command to check information about an IPv6 PIM routing table.
l Run the display pim ipv6 rp-info [ ipv6-group-address ] command to check information
about the RP in an IPv6 PIM-SM domain.
----End
Example
Run the display pim ipv6 bsr-info command. If Elected BSR Address displays the address of
the current BSR in the PIM-SM domain, Candidate BSR Address displays the address of the
C-BSR configured on the router, and State displays Elected, it means that the C-BSR is elected
as the BSR. For example:
<HUAWEI> display pim ipv6 bsr-info
Elected BSR Address: 2004::2
Priority: 0
State: Elected
Uptime: 00:00:07
C-RP Count: 0
Candidate BSR Address: 2004::2
Priority: 0
State: Elected
Wait to be BSR: 0
Run the display pim ipv6 interface command. You can view the number of PIM neighbors on
each interface and see that the PIM status on each interface is Up. For example:
<HUAWEI> display pim ipv6 interface
Eth3/0/1 up 1 30 1 FE80:1::3456
Run the display pim ipv6 neighbor command. You can view the number of PIM neighbors,
address of each neighbor, and interfaces where PIM neighbor relationships are set up. For
example:
<HUAWEI> display pim ipv6 neighbor


FE80:1::3456 Eth3/0/1 00:01:08 never 1 N
Run the display pim ipv6 routing-table command. You can view information about PIM
entries, such as the source address, group address, RP, upstream interface, and downstream
interface list. For example:
<HUAWEI> display pim ipv6 routing-table
(1000:2000::100, FF06::)
RP: NULL
Protocol: pim-sm, Flag: SPT NIIF SG_RCVR
UpTime: 00:00:14
Join/Prune FSM: [SPT: NJ] [RPT: NJ]
Downstream interface(s) information: none
(1000:2000::200, FF06::)
RP: NULL
UpTime: 00:00:14
Run the display pim ipv6 rp-info command. You can view information about an RP, such as
the address and priority of the RP and the range of multicast groups served by the RP. local
indicates that the local router is elected as the RP. For example:
<HUAWEI> display pim ipv6 rp-info ff0e::1
BSR RP Address is: 2001:AA::99
Priority: 192
Uptime: 00:00:52
Expires: 00:01:38
RP mapping for this group is: 2001:AA::99 (local host)
8.4 Configuring a BSR Boundary (IPv6)

Before configuring IPv6 PIM-SM inter-domain multicast, configure BSR boundaries to divide
a multicast network into PIM-SM domains. Each BSR serves only the local PIM-SM domain.
The routers outside the BSR boundary of a PIM-SM domain do not take part in BSR messages
forwarding in the PIM-SM domain.
After a BSR boundary is configured on an interface of the router on the edge of an IPv6 PIM-
SM domain, Bootstrap messages cannot pass through the BSR boundary. The interfaces
configured with BSR boundaries divide a network into several PIM-SM domains.
A BSR boundary can also be used to isolate a PIM-SM domain from the Internet.
Before configuring a BSR boundary, complete the following task:

l Configuring an IPv6 unicast routing protocol to ensure that IPv6 unicast routes are
reachable on the network
l Enabling IPv6 multicast routing on all the routers and enabling IPv6 PIM-SM on each
interface on the routers
Procedure
Step 1 Run:
system-view

Step 2 Run:
The view of the interface to be configured with a BSR boundary is displayed.

Step 3 Run:
pim ipv6 bsr-boundary
A BSR boundary is configured. Bootstrap messages cannot pass through the BSR boundary.
By default, all routers on an IPv6 PIM-SM network can receive Bootstrap messages.
Step 4 Run:
commit
----End

Run the display pim ipv6 bsr-info command to check information about the BSR in an IPv6
PIM-SM domain.
Follow-up Procedure
Perform the task of Configuring a BSR RP in each IPv6 PIM-SM domain.
8.5 Adjusting Dynamic RP Parameters (IPv6)

When a dynamic RP is used on a network, parameters of C-RPs and C-BSRs on the network
can be adjusted as needed.
Initially, each C-BSR considers itself as a BSR and sends a Bootstrap message to the entire
network. Each router receives the Bootstrap messages sent by all C-BSRs. By comparing the
information carried by the Bootstrap messages, the routers elect a BSR.
All the routers know the BSR address. The C-RPs send Advertisement messages to the BSR.
An Advertisement message sent by a C-RP carries the address of the C-RP, the range of multicast
groups that the C-RP serves, and the priority of the C-RP. The BSR collects C-RP information
and summarizes information into an RP-set, encapsulates the RP-set in a Bootstrap message,

and advertises the Bootstrap message to each router. Based on the RP-set, each router performs
the RP calculation by using the same rule and elects the RP for a specific group from multiple
C-RPs to which this group corresponds.
The router can work normally by using default parameter values. The NE5000E allows you to
adjust BSR RP parameters as needed.
NOTE
If there is no special requirement, default parameter values are recommended.
Before adjusting dynamic RP parameters, complete the following tasks:
l Configuring IPv6 PIM-SM and using a BSR RP
8.5.1 Adjusting C-RP Parameters

A C-RP periodically sends Advertisement messages to the BSR. Advertisement messages carry
information such as the priorities of C-RPs. You can adjust the priority of a C-BSR, interval for
sending Advertisement messages, and timeout period of an Advertisement message on a device
configured with C-RPs.
Context
An RP is elected from C-RPs based on the following rules:
l The C-RP that has the highest priority wins.

l In case of the same priority, hash functions are operated. The C-RP that has the greatest
calculated value wins.
l If all the preceding factors are the same, the C-RP that has the highest IPv6 address wins.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
c-rp priority priority
The global priority of a C-RP is configured.

The greater the priority value, the lower the priority. By default, the global priority of a C-RP
is 0.
Step 4 Run:
c-rp advertisement-interval interval
The interval at which a C-RP sends Advertisement messages is set.

By default, a C-RP sends Advertisement messages at an interval of 60s.
Step 5 Run:
c-rp holdtime interval
The period during which a BSR keeps the Advertisement message of a C-RP is set.
NOTE
The period during which a BSR keeps the Advertisement message of a C-RP must be greater than the
interval at which a C-RP sends Advertisement messages.
C-RPs periodically send Advertisement messages to the current BSR. The BSR extracts
Holdtime from the messages and starts a timer. If the BSR does not receive any Advertisement
message from a C-RP within the timeout period of the timer, it considers the C-RP invalid or
inaccessible.
By default, the BSR keeps the Advertisement messages from a C-RP for 150s.
Step 6 Run:
commit
----End
8.5.2 Setting the Range of Valid C-RP Addresses

The range of valid C-RP addresses and range of IPv6 multicast groups that each C-RP serves
can be configured to filter packets on all C-BSRs by using an IPv6 ACL. The BSR adds the C-
RP information contained in an Advertisement message received from a C-RP to the RP-set only
when the address of the C-RP and IPv6 multicast groups that the C-RP serves are within the
configured ranges respectively. This prevents C-RP spoofing.
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim-ipv6

Step 3 Run:
crp-policy { advanced-acl6-number | acl6-name acl6-name }
The range of valid C-RP addresses and the range of IPv6 multicast groups that a C-RP serves
are set.

l If the C-RP address or the address of a multicast group that a C-RP serves contained in an
Advertisement message is not within the range defined by an IPv6 ACL or no action is defined
in the IPv6 ACL for processing such an Advertisement message, the BSR discards the
Advertisement message and does not add the C-RP information carried by the Advertisement
message to the RP-set.
l If only advanced-acl6-number or acl6-name acl6-name is set but no IPv6 ACL is set, the
BSR denies all Advertisement messages.
By default, the BSR does not check the C-RP address or the range of IPv6 multicast groups that
a C-RP serves in a received Advertisement message. That is, the BSR considers all the received
C-RP information valid.
Step 4 Run:
commit
----End
8.5.3 Adjusting C-BSR Parameters

At first, each C-BSR considers itself as a BSR and sends a Bootstrap message to all devices.
You can adjust the C-BSR hash mask length and C-RP priority carried by a Bootstrap message,
interval for sending Bootstrap messages, and timeout period of a Bootstrap message on a device
configured with a C-BSR.
Context
A C-BSR is elected from C-BSRs based on the following rules:
l The C-BSR that has the highest priority wins.

l In case of the same priority, the C-BSR that has the highest IP address wins.
Based on the results of the BSR election, a C-BSR performs the following operations:
l If the C-BSR wins the BSR election, it periodically sends Bootstrap messages carrying its
IP address and RP-set information to the network where the C-BSR resides.
l If the C-BSR fails the BSR election, it is suppressed from sending Bootstrap messages.
l When the current BSR becomes faulty, the C-BSRs automatically trigger a new round of
BSR election to prevent service interruption.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6
Step 3 Run:
c-bsr hash-length hash-length

The global hash mask length is set for a C-BSR.
The hash mask length carried by a Bootstrap message is used for RP calculation. By default, the
global hash mask length of a C-BSR is 126.
Step 4 Run:
c-bsr priority priority
The global priority is set for a C-BSR.
The greater the priority value is, the higher the priority is. By default, the global priority of a C-
BSR is 0.
Step 5 Run:
c-bsr interval interval
The interval at which a C-BSR sends Bootstrap messages is set.
By default, a C-BSR sends Bootstrap messages at an interval of 60 seconds.
Step 6 Run:
c-bsr holdtime interval
The period during which the router keeps the Bootstrap message received from a BSR is set.
NOTE
The period during which the router holds the Bootstrap message received from the BSR must be greater
than the interval at which a C-BSR sends Bootstrap messages. Otherwise, BSR election is frequently
performed.
The BSR periodically sends Bootstrap messages over the network. After receiving the Bootstrap
messages, the router holds the messages for a certain period during which the BSR election is
suspended. If the period expires, the C-BSRs trigger a new round of BSR election.
By default, the router keeps the Bootstrap message received from a BSR for 130s.
Step 7 Run:
commit
----End
8.5.4 Setting the Range of Valid BSR Addresses

After an IPv6 ACL is used to configure the range of valid BSR addresses on all devices, only
the Bootstrap messages with source addresses within the range are accepted, thus preventing
BSR spoofing.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim-ipv6


Step 3 Run:
bsr-policy { basic-acl6-number | acl6-name acl6-name }
The range of valid BSR addresses is set.

l If the source address contained in a Bootstrap message is denied by the IPv6 ACL or no
action is defined in the IPv6 ACL for processing such a Bootstrap message, the router discards
this Bootstrap message.
l If basic-acl6-number or acl6-name acl6-name is specified but the corresponding IPv6 ACL
is not configured, the router denies all Bootstrap messages.
By default, the router does not check the source address of a received Bootstrap. That is, it
considers all received Bootstrap as valid.
Step 4 Run:
commit
----End

After adjusting dynamic RP parameters, you can run related commands to view BSR and RP
information.
Prerequisite
The adjustment of dynamic RP parameters on an IPv6 network is complete as needed.
Procedure
l Run the display pim ipv6 bsr-info command to check information about a BSR in an IPv6
PIM-SM domain.
l Run the display pim ipv6 rp-info [ ipv6-group-address ] command to check information
about an RP in an IPv6 PIM-SM domain.
----End
Example
Run the display pim ipv6 bsr-info command. You can view information about C-BSRs. For
example:
<HUAWEI> display pim ipv6 bsr-info
Priority: 0
State: Elected
Uptime: 00:00:07
C-RP Count: 0
Priority: 0


State: Elected
Wait to be BSR: 0
Run the display pim ipv6 rp-info command. You can view information about an RP, including
the RP address, RP priority, and range of groups served by the RP. For example:
<HUAWEI> display pim ipv6 rp-info ff0e::1
BSR RP Address is: 2001:AA::99
Priority: 192
Uptime: 00:00:52
Expires: 00:01:38
RP mapping for this group is: 2001:AA::99 (local host)
8.6 Configuring IPv6 PIM-SSM

PIM-SSM enables a user to specify a multicast source that will send data to a desired group.
PIM-SSM is implemented based on some PIM-SM technologies. In PIM-SSM, no RP needs to
be maintained and a dedicated multicast forwarding path is set up between a receiver and a
specified multicast source.
PIM-SSM uses only some PIM-SM technologies. In PIM-SSM, it is unnecessary to maintain an
RP, build an RPT, or register a multicast source. The DR is valid only on a shared network
segment connected to group members. Based on users' requirements, the receiver's DR sends a
Join message towards the multicast source. The Join message is transmitted upstream hop by
hop, and an (S, G) entry is created on each hop. An SPT is built from the router directly connected
to the multicast source to the receiver's DR.
PIM-SSM is used to implement IPv6 multicast when the following conditions are met:
l IPv6 multicast groups that users join are within the SSM group address range.
l The multicast source is specified when users join an IPv6 multicast group.
l routers run PIM-SM.
PIM-SM and PIM-SSM can be used together on a network to provide multicast services for
users. After configuring IPv6 PIM-SM on the network, you can adjust the SSM group address
range as needed. If an IPv6 multicast group that a user wants to join is beyond the SSM group
address range, PIM-SM can be used to forward IPv6 multicast packets.
Before configuring IPv6 PIM-SSM, complete the following task:

Figure 8-2 Flowchart for configuring IPv6 PIM-SSM
Enable IPv6 multicast routing
Enable IPv6 PIM-SM
Set an SSM group address

range
Limit the range of multicast

source addresses
Mandatory
procedure
Optional
procedure

router.
Procedure
Step 1 Run:
system-view
Step 2 Run:
CAUTION
Step 3 Run:
commit
----End


Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
pim ipv6 sm
CAUTION
the interface.
Step 4 Run:
commit
----End
8.6.3 Setting an SSM Group Address Range

The group address range in the PIM-SSM model is different from that in the PIM-SM model. If
a multicast group that a user wants to join is within the SSM group address range, the PIM-SSM
model is used to forward packets. If a multicast group that a user wants to join is beyond the
SSM group address range, the PIM-SM model is used to forward packets. In PIM-SSM model,
the default group address range is FF3x::/32. The SSM group address range can be changed as
needed.
Context
CAUTION
Ensure that the SSM group address ranges of all routers on an IPv6 network are identical.
Otherwise, faults may occur on the network.

Procedure
Step 1 Run:
system-view

Step 2 Run:
pim-ipv6

Step 3 Run:
ssm-policy { basic-acl6-number | acl6-name acl6-name }
An SSM group address range is set.

Step 4 Run:
commit
----End
8.6.4 (Optional) Limiting the Range of Multicast Source Addresses

After being configured with an IPv6 source address-based filtering policy by using an IPv6 ACL,
the IPv6 PIM router forwards only the multicast packets with source addresses or source/group
addresses being in the range defined by the IPv6 ACL.
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim-ipv6

Step 3 Run:
source-policy { acl6-number | acl6-name acl6-name }
The range of multicast source addresses is limited.

l If a basic IPv6 ACL is used, only the multicast data packets with source addresses being in
the range permitted by the IPv6 ACL can be forwarded.
l If an advanced IPv6 ACL is used, only the multicast data packets with source addresses and
group addresses being in the ranges permitted by the IPv6 ACL can be forwarded.
l If the specified IPv6 ACL does not exist, no multicast packets can be forwarded.
NOTE
The source-policy command cannot be used to filter static (S, G) entries.
Step 4 Run:
commit

----End

After configuring IPv6 PIM-SSM, you can view PIM interfaces, PIM neighbors, and PIM
routing tables by using related commands.
Prerequisite
The IPv6 PIM-SSM configurations are complete.
Procedure
command to check IPv6 PIM interfaces.
interface-number | verbose ] * command to check IPv6 PIM neighbors.
[ fsm ] command to check the IPv6 PIM routing table of a device.
----End
Example
each interface and see that the PIM status is Up on each interface. For example:
Eth3/0/1 up 1 30 1 FE80:1::3456
neighbor addresses, and interfaces that set up neighbor relationships. For example:

FE80:1::3456 Eth3/0/1 00:01:08 never 1 N
Run the display pim ipv6 routing-table command. You can view the source addresses, group
addresses in PIM entries, upstream interfaces, and downstream interface lists of PIM entries.
For example:
(1000:2000::100, FF06::)
RP: NULL
UpTime: 00:00:14


(1000:2000::200, FF06::)
RP: NULL
UpTime: 00:00:14
8.7 Adjusting Other IPv6 PIM Parameters

You can adjust the control parameters for maintaining neighbor relationships, DR parameters,
and control parameters for forwarding as needed.
Default parameter values allow the router to function properly. The NE5000E allows you to
adjust the control parameters for maintaining neighbor relationships, DR parameters, and control
parameters for forwarding as needed.
NOTE
If there is no special requirement, default parameter values are recommended.
Before adjusting other IPv6 PIM parameters, complete the following tasks:
l Configuring IPv6 PIM-SM or Configuring IPv6 PIM-SSM
8.7.1 Adjusting 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.
Procedure
Step 1 Run:
system-view

Step 2 Run:
pim-ipv6


Step 3 Run:
source-lifetime interval
The lifetime of a source is configured.

After receiving a multicast packet from S, the router resets the timer. If the timer times out, the
(S, G) entry is considered invalid.
Step 4 Run:
commit
----End
8.7.2 Adjusting Control Parameters for Maintaining Neighbor

Relationships
Devices set up neighbor relationships by exchanging Hello messages. The control parameters
for maintaining PIM neighbor relationships include the interval for send Hello messages, timeout
period of a neighbor relationship, whether to deny a Hello message carrying the Generation ID
option, and policy for filtering neighbors.
Context
You can the interval for sending Hello messages and the timeout period of a neighbor relationship
either globally or on an interface.

The following functions can be configured on interfaces to improve the security of IPv6 PIM
neighbors:
l Deny Hello messages without the Generation ID option. If the router finds that a Hello
message received from a PIM neighbor contains a different generation ID, the router
considers that the status of the PIM neighbor changes.
l Configure a neighbor filtering policy to limit the range of valid neighbor addresses. The
router discards a Hello message received from a neighbor with the address beyond the set
range.
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run
timer hello interval
The interval for sending Hello messages is set.
By default, the router sends Hello messages at an interval of 30 seconds.

4. Run:
hello-option holdtime interval
The timeout period of a neighbor is set. If a device does not receive any Hello message
from a neighbor within the timeout period, the device considers the neighbor
unreachable.
NOTE
The interval at which the router sends Hello messages must be shorter than the neighbor timeout
period.
By default, the timeout period of a neighbor is 150s.

5. Run:
commit

1. Run:
system-view

2. Run:
The IPv6 PIM interface view is displayed.

3. Run:
pim ipv6 timer hello interval
The interval at which the interface sends Hello messages is set.
By default, an interface sends Hello messages at an interval of 30s.

4. Run:
pim ipv6 hello-option holdtime interval
The neighbor timeout period is set on the interface. If the interface does not receive
any Hello packet from a neighbor within the timeout period from a neighbor, the
interface considers the neighbor unreachable.
NOTE
The interval at which the router sends Hello messages must be smaller than the neighbor timeout
period.
By default, the neighbor timeout period is 150s on an interface.

5. Run:
pim ipv6 require-genid
The interface is configured to accept the Hello messages with the Generation ID option
and deny the Hello messages without the Generation ID option.

By default, the router accepts the Hello messages without the Generation ID option.
6. Run:
pim ipv6 neighbor-policy { basic-acl6-number | acl6-name acl6-name }
A neighbor filtering policy is configured.

When being configured on an interface, the neighbor filtering function needs to be
configured on the routers that set up PIM neighbor relationships with this interface
accordingly.
By default, an interface does not filter IPv6 PIM neighbors.
7. Run:
commit

----End
8.7.3 Adjusting DR Parameters

The source's DR is responsible for sending Register messages to the RP, and the receiver's DR
is responsible for sending Join messages to the RP. Devices elect a DR by exchanging Hello
messages. The device with the highest priority wins the election. In the case of the same priority,
the device with the highest IP address wins the election.
Context
On an IPv6 PIM-SM network, the devices on a shared network segment need to elect a DR that
is responsible for the registration of multicast sources or the joining of receivers. The DR election
is based on priorities and IPv6 addresses. routers elect a DR by exchanging Hello messages
carrying their priorities.
l If all routers support the Hello messages carrying priorities, the PIM interface with the
highest priority is elected as a DR. In the case of the same priority, the interface with the
highest IPv6 address is elected as the DR.
l If one router does not support any Hello messages carrying priorities, the PIM interface
with the highest IPv6 address is elected as the DR.
You can configure a DR priority either globally or on an interface:
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

3. Run:
hello-option dr-priority priority
A priority is set for all the interfaces on the router that participate in the DR election.
The greater the priority value is, the higher the priority is. By default, the priority
values of all the interfaces on the router that participate in the DR election are 1.
4. Run:
commit

1. Run:
system-view

2. Run:

3. Run:
pim ipv6 hello-option dr-priority priority
The priority of the interface is set.

The greater the priority value is, the higher the priority is. By default, the priority of
an interface that participate in DR election is 1.
4. Run:
commit

----End
8.7.4 Adjusting Control Parameters for Forwarding

The control parameters for IPv6 PIM forwarding include the interval for sending Join/Prune
messages, holdtime carried by a Join/Prune message, policy for filtering Join/Prune messages,
and lan-delay and override-interval carried by a Hello message.
Context
The router sends a Join message to its upstream device to request required IPv6 multicast data
and a Prune message to request its upstream device to stop sending IPv6 multiast data.
l After the first device joins a multicast group, the router sends a Join message to request its
upstream router to forward required IPv6 multicast data.
On an IPv6 PIM-SM network, the router periodically sends Join messages to prevent RPT
branches from being pruned off due to timeout.
l After the last member of a group leaves the group, the router sends a Prune message to
request its upstream router to perform the prune action. If other downstream routers still
need to receive multicast data for the group, they must send Join messages to the upstream
router within the set override-interval to override the prune action.
A Hello message carries lan-delay and override-interval.

lan-delay specifies the delay in transmitting Prune messages on a shared network

segment.
override-interval specifies the interval for overriding the prune action.
The relationship between lan-delay, override-interval, and PPT is: lan-delay + override-
interval = PPT. The Prune-Pending Timer (PPT) indicates the period from the time when
the router receives a Prune message from a downstream interface to the time when the
router performs the prune action. If the router receives a Join message from the downstream
interface within the PPT, the router does not perform the prune action.
You can set control parameters for forwarding either globally or on an interface:
To enhance the security of IPv6 PIM forwarding, configure a source address- and group address-
based policy for filtering Join/Prune messages on an interface.
Procedure
1. Run:
system-view

2. Run:
pim-ipv6

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

By default, the interval for sending Join/Prune messages is 60s.
4. Run:
holdtime join-prune interval
The value of the holdtime field carried by a sent Join/Prune message is set.
After receiving a Join/Prune message from a downstream interface, an upstream
router determines the period for keeping the join or prune state of the downstream
interface based on the value of the holdtime field in the Join/Prune message.
The value of the holdtime field carried by a Join/Prune message must be 3.5 times of
the interval for sending Join/Prune messages. By default, the value of the holdtime
field carried by a sent Join/Prune message is 210s.
5. Run:
hello-option lan-delay interval
The value of the lan-delay field carried by a sent Hello message is set.
When the values of lan-delay fields carried by Hello messages sent by the interfaces
on a shared network segment are different, the largest one of these values is used. By
default, the value of the lan-delay field carried by a sent Hello message is 500 ms.

6. Run:
hello-option override-interval interval
The value of the override-interval field carried by a sent Hello message is set.
When the values of override-interval fields carried by Hello messages sent by the
interfaces on a shared network segment are different, the maximum one of these values
is used. By default, the value of the override-interval field carried by a sent Hello
message is 2500 ms.
7. Run:
neighbor-check { receive | send }
The neighbor check function is configured.

You can specify both receive and send to enable the IPv6 PIM neighbor check
function for both the received and sent Join/Prune messages and Assert messages.
8. Run:
commit

1. Run:
system-view

2. Run:

3. Run:
pim ipv6 timer join-prune interval
The interval at which the interface sends Join/Prune messages is set.

By default, an interface sends Join/Prune messages at an interval of 60s.
4. Run:
pim ipv6 holdtime join-prune interval
The value of the holdtime field carried by a Join/Prune message sent by the interface
is set.
By default, the value of the holdtime field carried by a Join/Prune message sent by an
interface is 210s.
5. Run:
pim ipv6 hello-option lan-delay interval
The value of the lan-delay field carried by a Hello message sent by the interface is set.
By default, the value of the lan-delay field carried by a Hello message sent by the
interface is 500 ms.
6. Run:
pim ipv6 hello-option override-interval interval
The value of the override-interval field carried by a Hello message sent by the interface
is set.

By default, the value of the override-interval field carried by a Hello message sent by
the interface is 2500 ms.
7. Run:
pim ipv6 join-policy { { advanced-acl6-number | acl6-name acl6-name } |
asm { basic-acl6-number | acl6-name acl6-name } | ssm { advanced-acl6-
number | acl6-name acl6-name } }
A policy for filtering Join messages contained in Join/Prune messages is configured.

8. Run:
commit

----End
8.7.5 Adjusting Assert Parameters

The router that fails in an election prohibits its downstream interface from forwarding multicast
data in the period during which the router keeps the Assert state. After the period expires, the
router restores the forwarding capability of its downstream interface.
Context
Other multicast forwarders exist on a network segment if the following condition is met:
The interface that receives a multicast packet is a downstream interface in the corresponding (S,
G) entry on the local router.
If the preceding conditions are met, the router sends an Assert message through the downstream
interface. At the same time, the downstream interface also receives an Assert message from
another multicast forwarder on the network segment. The router compares its information with
the information carried in the message sent by other forwarders. This process is called an Assert
election.
l If the router wins, the downstream interface keeps the forwarding state and forwards (S,
G) data packets on the network segment. The downstream interface is called an Assert
winner.
l If the router fails, the downstream interface is prohibited from forwarding multicast packets
and deleted from the downstream interface list of the (S, G) entry. The downstream interface
is called an Assert loser.
All Assert losers can periodically restore multicast packet forwarding, thereby causing
periodical Assert elections.
You can set the period during which an Assert loser keeps the Assert state either globally or on
an interface.
Procedure
1. Run:
system-view


2. Run:
pim-ipv6

3. Run:
holdtime assert interval
The period during which the interface keeps the Assert state is set.
By defaults, all the interfaces of the router keep the Assert state for 180s.
4. Run:
commit

1. Run:
system-view

2. Run:

3. Run:
pim ipv6 holdtime assert interval
The period during which the interface keeps the Assert state is set.
By defaults, the interface keeps the Assert state for 180s.
4. Run:
commit

----End

After adjusting control parameters for maintaining PIM neighbor relationships, control
parameters for forwarding, and Assert parameters, you can view PIM interfaces, PIM neighbors,
PIM routing tables, and statistics about PIM control messages by using related commands.
Prerequisite
The adjustments of control parameters for maintaining PIM neighbor relationships, DR
parameters, control parameters for forwarding, and Assert parameters are complete.
Procedure
command to check information about IPv6 PIM interfaces.
interface-number | verbose ] * command to check information about IPv6 PIM neighbors.


[ fsm ] command to check information about an IPv6 PIM routing table.
l Run the display pim ipv6 control-message counters [ message-type { assert | bsr | crp
| hello | join-prune | probe | register | register-stop } ] command to check the statistics
about IPv6 PIM control parameters.
----End
Example
each interface and see that the PIM status on each interface is Up. For example:
Eth3/0/1 up 1 30 1 FE80:1::3456
address of each neighbor, and interfaces where PIM neighbor relationships are set up. For
example:

FE80:1::3456 Eth3/0/1 00:01:08 never 1 N
Run the display pim ipv6 routing-table command. You can view information about PIM
entries, such as the source address, group address, RP, upstream interface, and downstream
interface list. For example:
(1000:2000::100, FF06::)
RP: NULL
UpTime: 00:00:14
(1000:2000::200, FF06::)
RP: NULL
UpTime: 00:00:14
Run the display pim ipv6 control-message counters command. You can view the number of
received packets, sent packets, invalid packets, or filtered out packets. For example:
<HUAWEI> display pim ipv6 control-message counters interface gigabitethernet 1/0/0
PIM control-message counters for interface: GigabitEthernet1/0/0

Message Type Received Sent Invalid Filtered

Assert 0 0 0 0
Graft 0 0 0 0
Graft-Ack 0 0 0 0
Hello 328 331 0 0
Join-prune 2 0 0 0
State-Refresh 0 0 0 0
BSR 9778 0 0 0
8.8 Maintaining IPv6 PIM

Maintaining IPv6 PIM includes resetting statistics about IPv6 PIM control messages, monitoring
the operating status of IPv6 PIM, and debugging IPv6 PIM.
8.8.1 Resetting Statistics About IPv6 PIM Control Messages

To re-collect statistics about IPv6 PIM control messages, clear the existing statistics about IPv6
PIM control messages by using reset commands. The statistics cannot be restored after being
reset. Exercise caution when running reset commands.
Context
CAUTION
The statistics about IPv6 PIM control messages on an interface cannot be restored after being
reset. Exercise caution when running reset commands.
Procedure
Step 1 Run the reset pim ipv6 control-message counters [ interface interface-type interface-
number ] command in the user view to reset statistics about IPv6 PIM control messages on a
specified interface.
----End
8.8.2 Monitoring the Operating Status of IPv6 PIM

You can monitoring the operating status of IPv6 PIM by viewing unicast routes used by IPv6
PIM, BSRs, RPs, statistics about PIM control messages, PIM neighbors, and PIM routing tables.
Context
In routine maintenance, you can run the following commands in any view to view the operating
status of IPv6 PIM.
Procedure
l Run the display pim ipv6 claimed-route [ source-address ] command to view unicast
routes used by IPv6 PIM.
l Run the display pim ipv6 bsr-info command to view information about a BSR in an IPv6
PIM-SM domain.

l Run the display pim ipv6 control-message counters [ interface interface-type interface-
number ] [ message-type { assert | bsr | crp | graft | graft-ack | hello | join-prune | state-
refresh } ] command to view statistics about IPv6 PIM control messages.
command to view IPv6 PIM interfaces.
interface-number | verbose ] * command to view IPv6 PIM neighbors.
[ fsm ] command to view the IPv6 PIM routing table.
l Run the display pim ipv6 rp-info [ ipv6-group-address ] command to view information
about an RP in an IPv6 PIM-SM domain.
----End

This section provides several IPv6 PIM configuration examples showing how to build up a basic
IPv6 PIM network and how to configure basic IPv6 PIM functions.
8.9.1 Example for Configuring IPv6 PIM-SM Intra-domain

Multicast
After basic PIM-SM functions are configured in an AS where IPv6 unicast routing works
properly, users in the AS can receive data sent from any multicast source.
CAUTION
slot number.
deployed to ensure that IPv6 unicast routes are available. The ISP network is connected to the
Internet. Hosts on this network must be able to receive VoD information in multicast mode.

Figure 8-3 Networking diagram of configuring IPv6 PIM-SM intra-domain multicast
RouterB HostA
GE2/0/0
3001::1
POS1/0/0
2002::2
POS3/0/0 HostB
2004::1
POS2/0/0
2002::1 POS2/0/0
RouterA 2003::1 2004::2
POS3/0/0 RouterD
GE1/0/0 POS1/0/0
2001::1 POS4/0/0 2003::2 POS3/0/0
Source 2006::1 2005::1
2001::5
POS1/0/0
2005::2 HostC
Internet
GE2/0/0
4001::2 HostD
RouterC
Precautions
When configuring IPv6 PIM-SM intra-domain multicast, note the following points:
l IPv6 PIM-SM and then MLD need to be enabled on the interface connected to hosts.
l When users need to receive data sent by a specified multicast source, PIM-SSM needs to
be enabled, and the same SSM group address range needs to be configured on all the
routers.
The configuration roadmap is as allows:
1. Configure an IPv6 address for each interface on the routers and configure an IPv6 unicast
routing protocol.
3. Enable IPv6 PIM-SM on all the interfaces of IPv6 multicast routers.
4. Enable MLD on the interface that directly connects the router to hosts.
5. Configure an RP. An RP is the root node of an RPT on a PIM-SM network. Setting an RP
on the router that has more multicast flows is recommended.
messages cannot pass through the BSR boundary. Therefore, the BSR serves only this PIM-
SM domain. This improves multicast controllability.

7. (Optional) Configure the same SSM group address range on each router. This enables the
multicast routers in the PIM-SM domain to provide services only for multicast groups with
addresses being in the SSM group address range.
Data Preparation

Procedure
Step 1 Configure an IPv6 address for each interface on the routers and configure an IPv6 unicast routing
protocol. The configuration details are not provided here.
Step 2 Enable IPv6 multicast on each router and IPv6 PIM-SM on each interface on the routers.
# The configurations of Router B, Router C, and Router D are similar to those of Router A, and
are not provided here.
[~RouterA] multicast ipv6 routing-enable
[~RouterA-GigabitEthernet1/0/0] pim ipv6 sm
[~RouterA-Pos2/0/0] pim ipv6 sm
# Run the display pim ipv6 interface command to check IPv6 PIM interfaces on each router.
For example, the information about IPv6 PIM interfaces on Router B is displayed:
<RouterB> display pim ipv6 interface
Pos1/0/0 up 1 30 1 FE80::A01:10E:1 (local)
GE2/0/0 up 0 30 1 FE80::200:AFF:FE01:10E
(local)
Pos3/0/0 up 1 30 1 FE80::9D62:0:FDC5:2
Step 3 Enable MLD on the interface directly connected to hosts.
# The configuration of Router C is similar to that of Router B, and is not provided here.
[~RouterB-GigabitEthernet2/0/0] mld enable
[~RouterB-GigabitEthernet2/0/0] commit

NOTE
preferred by setting preferred in the static-rp rp-address command.
In this configuration example, a dynamic RP is used.
PIM-SM domain. On Router D, set the range of groups severed by the RP and locations of C-
BSRs and C-RPs.
[~RouterD] acl ipv6 number 2001
[~RouterD-acl6-basic-2001] rule permit source ff3e::1 64
[~RouterD-acl6-basic-2001] quit
[~RouterD] pim-ipv6
[~RouterD-pim6] c-rp 2004::2 group-policy 2001
# Configure C-BSRs on Router D.

[~RouterD-pim6] c-bsr 2004::2
# Run the display pim ipv6 bsr-info command to check BSR information on each router. For
example, the BSR information on Router B and Router D (C-BSR information is also displayed
on Router D) is displayed:
<RouterB> display pim ipv6 bsr-info
Priority: 0
Uptime: 00:04:22
Expires: 00:01:46
C-RP Count: 1
<RouterD> display pim ipv6 bsr-info
Priority: 0
State: Elected
Uptime: 00:01:10
C-RP Count: 1
Priority: 0
State: Elected
Wait to be BSR: 0
# Run the display pim ipv6 rp-info command to check RP information on each router. For
example, the RP information on Router B is displayed:
<RouterB> display pim ipv6 rp-info
Group/MaskLen: FF3E::1/64
RP: 2004::2
Priority: 192
Uptime: 00:05:19
Expires: 00:02:11
Step 5 (Optional) Configure a BSR boundary on the interface that connects Router A to the Internet.


[~RouterA-Pos4/0/0] pim ipv6 bsr-boundary
Step 6 (Optional) Configure the SSM group address range.

# Configure the SSM group address range to FF3E::1/64 on all routers. The configurations of
Router B, Router C, and Router D are similar to those on Router A, and are not provided here.
[~RouterA] acl ipv6 2000
[~RouterA-acl6-basic-2000] rule permit source FF3E::1 64
[~RouterA] pim-ipv6
[~RouterA-pim6] ssm-policy 2000

# Configure the multicast source S (2001::5) to send multicast packets to multicast group FF3E::
1 (within the SSM group address range) and multicast group FF0E::1 (beyond the SSM group
address range). Host A and Host C want to receive information for multicast group FF0E::1.
Host B wants to receive multicast information sent by S (2001::5) to multicast group FF3E::1.
# Run the display pim ipv6 routing-table command to check the IPv6 PIM routing table on
each router.
(2001::5, FF0E::1)
RP: 2004::2
UpTime: 00:02:15
1: Register
2: Pos2/0/0
3: Pos3/0/0
(2001::5, FF3E::1)
Protocol: pim-ssm, Flag: LOC SG_RCVR
UpTime: 00:00:11
1: Pos2/0/0
<RouterB> display pim ipv6 routing-table
(*, FF0E::1)
RP: 2004::2
UpTime: 00:14:44
Upstream neighbor: FE80::9D62:0:FDC5:2
RPF prime neighbor: FE80::9D62:0:FDC5:2


(2001::5, FF0E::1)
RP: 2004::2
UpTime: 00:2:42
Upstream neighbor: FE80::A01:10C:1
RPF prime neighbor: FE80::A01:10C:1
(2001::5, FF3E::1)
Protocol: pim-ssm, Flag: SG_RCVR
UpTime: 00:08:02
Protocol: pim-ssm, UpTime: 00:08:02, Expires: -
<RouterC> display pim ipv6 routing-table
(*, FF0E::1)
RP: 2004::2
UpTime: 00:14:44
Upstream neighbor: FE80::7493:FE25:1
RPF prime neighbor: FE80::7493:FE25:1
(2001::5, FF0E::1)
RP: 2004::2
UpTime: 00:2:42
(*, FF0E::1)
RP: 2004::2 (local)
UpTime: 00:16:56
1: Pos2/0/0
2: Pos3/0/0
(2001::5, FF0E::1)
RP: 2004::2 (local)
Protocol: pim-sm, Flag: SWT ACT
UpTime: 00:02:54
Upstream neighbor: FE81::659:10C:3

RPF prime neighbor: FE81::659:10C:3

1: Pos3/0/0
----End
Configuration Files
#
sysname RouterA
#
#
rule 0 permit source FF3E::1/64
#
undo shutdown
ipv6 enable
pim ipv6 sm
ospfv3 1 area 0.0.0.0
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
interface Pos4/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
ospfv3 1
router-id 1.1.1.1
area 0.0.0.0
#
pim-ipv6
ssm-policy 2000
#
return

#
sysname RouterB
#
#

#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
undo shutdown
ipv6 enable
pim ipv6 sm
mld enable
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
ospfv3 1
router-id 2.2.2.2
area 0.0.0.0
#
pim-ipv6
ssm-policy 2000
#
return
#
sysname RouterC
#
#
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
undo shutdown
ipv6 enable
pim ipv6 sm
mld enable
#
ospfv3 1
router-id 3.3.3.3
area 0.0.0.0
#
pim-ipv6
ssm-policy 2000
#
return
#

sysname RouterD
#
#
#
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
ospfv3 1
router-id 4.4.4.4
area 0.0.0.0
#
pim-ipv6
ssm-policy 2000
c-bsr 2004::2
c-rp 2004::2 group-policy 2001
#
return
8.9.2 Example for Configuring IPv6 PIM-SM Security

On an IPv6 PIM network, various filtering policies including valid source address ranges and
valid C-RP address ranges can be configured to protect the devices against malicious packet
attacks. This improves network security.
CAUTION
slot number.
As shown in Figure 8-4, IPv6 multicast services are deployed on the ISP network. An IGP has
been deployed to ensure that unicast routes are available. A filtering policy must be configured

on the router to enable users to receive correct IPv6 multicast data and to improve the security
of the IPv6 multicast network.
Figure 8-4 Networking diagram for configuring IPv6 PIM-SM security
RouterB HostA
GE2/0/0
3001::1
POS1/0/0
2002::2
POS3/0/0 HostB
2004::1
POS2/0/0
2002::1 POS2/0/0
RouterA 2003::1 2004::2
POS3/0/0 RouterD
GE1/0/0 POS1/0/0
2001::1 POS4/0/0 2003::2 POS3/0/0
Source 2006::1 2005::1
2001::5
POS1/0/0
2005::2 HostC
Internet
GE2/0/0
4001::2 HostD
RouterC
Precautions
When configuring IPv6 PIM-SM security, note the following points:
l IPv6 PIM-SM and then MLD need to be enabled on the interface connected to hosts.
l The range of multicast groups that each C-RP serves and the range of valid C-RP addresses
need to be configured on all the C-BSRs.
l Source address-based and BSR address-based filtering policies need to be configured on
all the routers.
l A policy for filtering Register messages needs to be configured on all C-RPs.
l The policy for filtering Join/Prune messages needs to be configured on the last-hop
router.
Filtering policies such as the source address-based filtering policy, BSR address-based filtering
policy, RP address-based filtering policy, Register message filtering policy, Join/Prune message
filtering policy, and PIM neighbor filtering policy are used to ensure the security of an IPv6
PIM-SM network. The configuration roadmap is as follows:
1. Configure an IPv6 address for each interface on the routers and configure an IPv6 unicast
routing protocol.

3. Enable IPv6 PIM-SM on all the interfaces of IPv6 multicast routers.
4. Enable MLD on the interface that directly connects the router to hosts.
5. Configure C-BSRs and C-RPs to elect an RP.
6. Configure the range of multicast groups that each C-RP serves on the C-BSRs.
7. Configure a policy for filtering Register messages on each C-RP to guard against the attacks
of Register messages carrying invalid multicast source information.
8. Configure a source address-based filtering policy on all the routers to deny the multicast
packets carrying invalid source addresses.
9. Configure a BSR address-based filtering policy on all the routers to prevent BSR spoofing.
Data Preparation
l ACL rules required by various filtering policies
Procedure
Step 1 Configure an IPv6 address for each interface on the routers and configure an IPv6 unicast routing
protocol. The configuration details are not provided here.
Step 2 Enable IPv6 multicast on all the routers and IPv6 PIM-SM on each interface on the routers.
Step 3 Enable MLD on the interfaces connected to hosts.

# The configuration of Router C is similar to that of Router B, and is not provided here.
[~RouterB-GigabitEthernet2/0/0] mld enable
[~RouterB-GigabitEthernet2/0/0] commit

# Configure the locations of C-BSRs and C-RPs on Router D.
[~RouterD] pim-ipv6
[~RouterD-pim6] c-rp 2004::2
[~RouterD-pim6] c-bsr 2004::2

Step 5 Configure the range of multicast groups that each C-RP serves and the range of valid C-RP
addresses on the C-BSRs.
# On Router D, configure the range of multicast groups served by each C-RP to ff0e::1/64 and
the range of valid C-RP addresses to 2004::2/128.
[~RouterD-acl6-advance-3000] rule permit source 2004::2 128 destination ff0e::1 64
[~RouterD-acl6-advance-3000] quit
[~RouterD] pim-ipv6
[~RouterD-pim6] crp-policy 3000
Step 6 Configure a policy for filtering Register messages on all the C-RPs.
# On Router D, configure a policy for filtering Register messages, allowing an RP to receive
only Register messages sent by multicast sources in the range of 2001::5/64 to multicast groups
in the range of ff0e::1/64.
[~RouterD-acl6-advance-3001] rule permit source 2001::5 64 destination ff0e::1 64
[~RouterD-acl6-advance-3001] quit
[~RouterD] pim-ipv6
[~RouterD-pim6] register-policy 3001
Step 7 Configure source address-based and BSR address-based filtering policies on all the routers.
[~RouterA-acl6-basic-2000] rule permit source 2001::5 64
[~RouterA-acl6-basic-2001] rule permit source 2004::2 64
[~RouterA] pim-ipv6
[~RouterA-pim6] source-policy 2000
[~RouterA-pim6] bsr-policy 2001

# Run the display pim ipv6 bsr-info command to check BSR information on each router. You
can see that the BSR address-based filtering policy takes effect. For example, the BSR
information on Router B and Router D is displayed:
<RouterB> display pim ipv6 bsr-info
Priority: 0
Uptime: 00:04:22
Expires: 00:01:46
C-RP Count: 1
<RouterD> display pim ipv6 bsr-info

Priority: 0
State: Elected
Uptime: 00:01:10
C-RP Count: 1
Priority: 0
State: Elected
Wait to be BSR: 0
# Run the display pim ipv6 rp-info command to check RP information on each router. For
example, the RP information on Router B is displayed:
<RouterB> display pim ipv6 rp-info
Group/MaskLen: FF3E::1/64
RP: 2004::2
Priority: 192
Uptime: 00:05:19
Expires: 00:02:11
# Configure the multicast source S (2001::5) to send multicast packets to multicast group FF3E::
1 (within the SSM group address range) and multicast group FF0E::1 (beyond the SSM group
address range). Host A and Host C want to receive information of multicast group FF0E::1. Host
B wants to receive multicast information sent by S (2001::5) to multicast group FF3E::1. The
hosts can receive multicast data sent by the valid multicast source. # Run the display pim ipv6
routing-table command to check the IPv6 PIM routing table on each router.
(2001::5, FF0E::1)
RP: 2004::2
UpTime: 00:02:15
1: Register
2: Pos2/0/0
3: Pos3/0/0
(2001::5, FF3E::1)
Protocol: pim-ssm, Flag: LOC SG_RCVR
UpTime: 00:00:11
1: Pos2/0/0
<RouterB> display pim ipv6 routing-table
(*, FF0E::1)
RP: 2004::2
UpTime: 00:14:44

Upstream neighbor: FE80::9D62:0:FDC5:2

RPF prime neighbor: FE80::9D62:0:FDC5:2
(2001::5, FF0E::1)
RP: 2004::2
UpTime: 00:2:42
(2001::5, FF3E::1)
Protocol: pim-ssm, Flag: SG_RCVR
UpTime: 00:08:02
Protocol: pim-ssm, UpTime: 00:08:02, Expires: -
<RouterC> display pim ipv6 routing-table
(*, FF0E::1)
RP: 2004::2
UpTime: 00:14:44
(2001::5, FF0E::1)
RP: 2004::2
UpTime: 00:2:42
(*, FF0E::1)
RP: 2004::2 (local)
UpTime: 00:16:56
1: Pos2/0/0
2: Pos3/0/0
(2001::5, FF0E::1)

RP: 2004::2 (local)

Protocol: pim-sm, Flag: SWT ACT
UpTime: 00:02:54
Upstream neighbor: FE81::659:10C:3
RPF prime neighbor: FE81::659:10C:3
1: Pos3/0/0
----End
Configuration Files
#
sysname RouterA
#
#
#
undo shutdown
ipv6 enable
pim ipv6 sm
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
interface Pos4/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
ospfv3 1
router-id 1.1.1.1
area 0.0.0.0
#
pim-ipv6
ssm-policy 2000
#
return

#
sysname RouterB

#
#
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
undo shutdown
ipv6 enable
pim ipv6 sm
mld enable
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
ospfv3 1
router-id 2.2.2.2
area 0.0.0.0
#
pim-ipv6
ssm-policy 2000
#
return
#
sysname RouterC
#
#
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
#
undo shutdown
ipv6 enable
pim ipv6 sm
mld enable
#
ospfv3 1
router-id 3.3.3.3
area 0.0.0.0
#
pim-ipv6
ssm-policy 2000

#
return

#
sysname RouterD
#
ipv6
#
#
#
#
interface Pos1/0/0
undo shutdown
ipv6 enable
link-protocol ppp
pim ipv6 sm
#
interface Pos2/0/0
undo shutdown
ipv6 enable
link-protocol ppp
pim ipv6 sm
#
interface Pos3/0/0
undo shutdown
ipv6 enable
link-protocol ppp
pim ipv6 sm
#
ospfv3 1
router-id 4.4.4.4
area 0.0.0.0
#
pim-ipv6
c-bsr 2004::2
c-rp 2004::2 group-policy 2001
#
pim-ipv6
ssm-policy 2000
#
return

Configuration Guide - IP Multicast 9 IPv6 Multicast Routing Management
9 IPv6 Multicast Routing Management
About This Chapter
IPv6 multicast routing management enables a system to maintain multiple IPv6 multicast routing
protocols and control multicast routing and forwarding by exchanging messages between the
control plane and the forwarding plane.
9.1 Overview of IPv6 Multicast Routing Management

IPv6 multicast routing and forwarding is based on IPv6 multicast routing and forwarding tables.
IPv6 multicast routing management functions to control the multicast routing and forwarding.
9.2 IPv6 Multicast Route Management Features Supported by the NE5000E
IPv6 multicast route management features supported by the NE5000E include IPv6 multicast
load splitting and control of the multicast forwarding scope.
9.3 Configuring IPv6 Multicast Load Splitting
IPv6 multicast load splitting is applicable to the scenario where multiple equal-cost IPv6 unicast
routes of the same type exist. If multiple equal-cost routes exist on a network, IPv6 multicast
load splitting can be performed for multicast traffic based on different policies. This optimizes
network traffic transmission in the case of multiple IPv6 multicast data flows.
9.4 Controlling the IPv6 Multicast Forwarding Range
Multicast data for each multicast group on an IPv6 network needs to be transmitted in a certain
range. You can control the IPv6 multicast forwarding range by setting a minimum TTL value
for IPv6 multicast packets or an IPv6 multicast forwarding boundary.
This section provides an example for configuring IPv6 multicast load splitting.

9.1 Overview of IPv6 Multicast Routing Management

IPv6 multicast routing and forwarding is based on IPv6 multicast routing and forwarding tables.
IPv6 multicast routing management functions to control the multicast routing and forwarding.
In IPv6 multicast implementation on the NE5000E, IPv6 multicast routing and forwarding
involves two aspects:
l Each multicast routing protocol has a routing table, for example, a PIM routing table.
l Routing entries of each protocol are directly delivered to a multicast forwarding table and
the multicast forwarding table controls the forwarding of multicast data packets.
Multicast routing protocols use the Reverse Path Forwarding (RPF) to generate multicast routing
entries, ensuring that multicast data packets are transmitted along correct paths. A system
performs an RPF check based on the following types of routes:
l IPv6 unicast routes

An IPv6 unicast routing table has shortest paths to all destinations.
l Static IPv6 multicast routes
A static IPv6 multicast routing table contains statically configured RPF routes.
IPv6 multicast route management is used to manage IPv6 multicast routing tables, control the
generation of IPv6 multicast routes, and change IPv6 multicast RPF routes.
9.2 IPv6 Multicast Route Management Features Supported

by the NE5000E
IPv6 multicast route management features supported by the NE5000E include IPv6 multicast
load splitting and control of the multicast forwarding scope.
IPv6 Multicast Load Splitting

By default, the router running IPv6 multicast selects the outbound interface of the optimal route
to the mutlicast source or RP to receive packets. If multiple optimal routes exist, the router selects
the outbound interface of the optimal route with the highest next hop address. If multiple equal-
cost unicast routes exist, multicast load splitting can be implemented among the routes based on
configured policies.
There are four multicast load splitting policies: stable-preferred, source address-based, group
address-based, and source and group addresses-based. The four load splitting policies are
mutually exclusive.
Control of the IPv6 Multicast Forwarding Range

On an IPv6 network, the multicast information to which each multicast group corresponds is
transmitted in a certain range. The NE5000E allows you to define the multicast forwarding range
by using either of the following methods:
l Set the TTL threshold for IPv6 multicast forwarding on an interface to limit the transmission
distance of multicast packets.

l Configure an IPv6 multicast forwarding boundary on an interface to form a closed multicast

forwarding area.
9.3 Configuring IPv6 Multicast Load Splitting

IPv6 multicast load splitting is applicable to the scenario where multiple equal-cost IPv6 unicast
routes of the same type exist. If multiple equal-cost routes exist on a network, IPv6 multicast
load splitting can be performed for multicast traffic based on different policies. This optimizes
network traffic transmission in the case of multiple IPv6 multicast data flows.
Context
IPv6 multicast routing is based on the RPF check. Based on RPF check results, the router selects
only one route for forwarding IPv6 multicast data. In the case of heavy IPv6 multicast traffic,
network congestion may occur, which will affect IPv6 multicast services.
IPv6 multicast load splitting extends multicast route selection rules. It solves the problem that
the multicast route selection completely depends on the RPF check. After multicast load splitting
is configured on a network with multiple equal-cost and optimal routes, devices may select all
the equal-cost routes for forwarding IPv6 multicast data.
Before configuring IPv6 multicast load splitting, complete the following tasks:
l Configuring basic IPv6 multicast functions
Procedure
Step 1 Run:
system-view
Step 2 Run:
multicast ipv6 load-splitting { stable-preferred | source | group | source-group }
IPv6 multicast load splitting is configured.
l stable-preferred: indicates stable-preferred load splitting. This policy is applicable to the

scenario where IPv6 multicast services are stable.
When equal-cost routes are added or deleted, the router automatically balances entries;
however, when IPv6 multicast routing entries are deleted, the router does not automatically
adjust the entries on the equal-cost routes.
l group: indicates group address-based load splitting. This policy is applicable to the scenario
of one source to multiple groups.
l source: indicates source address-based load splitting. This policy is applicable to the scenario
of one group to multiple sources.
l source-group: indicates source and group addresses-based load splitting. This policy is
applicable to the scenario of multiple sources to multiple groups.

Step 3 Run:
commit
----End

Run the display multicast ipv6 rpf-info ipv6-source-address command. You can view the RPF
routing information of a specified multicast source, RPF interface, RPF neighbor, preferred route
and its type, and configured IPv6 multicast load splitting policy. For example:
<HUAWEI> display multicast ipv6 rpf-info 2001::5
RPF information about source: 2001::5
RPF interface: GigabitEthernet6/0/0, RPF neighbor: 2001::2
Referenced route/mask: 2001::/64
Load splitting rule: stable-preferred
9.4 Controlling the IPv6 Multicast Forwarding Range

for IPv6 multicast packets or an IPv6 multicast forwarding boundary.
range. The NE5000E supports the following methods for controlling the IPv6 multicast
forwarding range:
l Configure an IPv6 multicast forwarding boundary on an interface to form a closed multicast

forwarding area. After an interface is configured with a forwarding boundary for a specific
group, the interface does not forward or receive any IPv6 multicast packet for this group.
l Set a minimum TTL value for IPv6 multicast packets to restrict the transmission distance
of IPv6 multicast packets. The interface forwards only the IPv6 multicast packets with the
TTL value being equal to or greater than the minimum TTL value. If the TTL value of a
packet is smaller than the minimum TTL value, the interface discards the packet.
Before controlling the IPv6 multicast forwarding range, complete the following tasks:
l Configuring an IPv6 unicast routing protocol to ensure normal IPv6 unicast routing on the
network
l Configuring basic IPv6 multicast functions

9.4.1 Setting a Minimum TTL Value for IPv6 Multicast Packets

for IPv6 multicast packets.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
multicast ipv6 minimum-ttl ttl-value
A minimum TTL value is set for IPv6 multicast packets.

By default, the minimum TTL value of IPv6 multicast packets allowed to be sent is 1.
Step 4 Run:
commit
----End
9.4.2 Configuring an IPv6 Multicast Forwarding Boundary

After an interface is configured with a forwarding boundary for a specific group, the interface
does not forward or receive any IPv6 multicast packet for this group.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
multicast ipv6 boundary ipv6-group-address ipv6-group-mask-length
An IPv6 multicast forwarding boundary is configured.

By default, an interface does not restrict the IPv6 multicast forwarding range.
Step 4 Run:
commit

----End

This section provides an example for configuring IPv6 multicast load splitting.
9.5.1 Example for Configuring IPv6 Multicast Load Splitting

On an IPv6 PIM-SM network stably running multicast services, you can configure a stable-
preferred IPv6 load splitting policy to balance IPv6 traffic among equal-cost routes.
CAUTION
slot number/card number/interface number. If the slot number is specified, the chassis ID of the
slot must also be specified.
On the network shown in Figure 9-1, Host A needs to steadily receive multicast data from the
multicast source and there are three equal-cost routes between Host A and the multicast source.
A multicast load splitting policy is required to evenly distributes entries to equal-cost routes,
thereby implementing load balancing among the equal-cost routes.
Figure 9-1 Networking diagram of configuring IPv6 multicast load splitting
Source
PIM-SM
0 /0 PO
S 2/0 /
1
OS1/ RouterB S2/0 /0 POS1/
GE1/0/0 PO P 0 /1
POS2/0/2 POS1/0/2 GE2/0/0
POS POS1/0/0 POS2/0/0 /3
0
RouterA
2/0 /
3 RouterC S1/ RouterE
PO
POS 0 /0 HostA
1/0 / S2/
Loopback0 0 PO
RouterD

Router A GE 1/0/0 2001::2/64 Router C POS 1/0/0 2003::2/64
POS 2/0/1 2002::1/64 POS 2/0/0 2006::1/64
POS 2/0/2 2003::1/64 Router D POS 1/0/0 2004::2/64
POS 2/0/3 2004::1/64 POS 2/0/0 2007::1/64
LoopBack0 2000::1/64 Router E POS 1/0/1 2005::2/64
Router B POS 1/0/0 2002::2/64 POS 1/0/2 2006::2/64
POS 2/0/0 2005::1/64 POS 1/0/3 2007::2/64
GE 2/0/0 3001::1/64
Precautions
When configuring IPv6 multicast load splitting, note the following points:
l Four IPv6 load splitting policies are mutually exclusive. You can configure one policy as
required.
1. Configure IPv6 addresses for interfaces on each router.

2. Configure IS-IS IPv6 to make all router routable and set the costs of the routes to be the
same.
3. Enable IPv6 multicast on each router and IPv6 PIM-SM on each interface of the routers.
Configure the loopback interface on Router A as an RP.
4. Configure stable-preferred IPv6 multicast load splitting on Router E to ensure the stability
of IPv6 multicast services.
5. Because Host A requires to receive data from some multicast groups for a long period,
configure the interfaces at the host side Router E to statically join the multicast groups in
batches.
Data Preparation
l IPv6 address of the multicast source

l IPv6 addresses for interfaces on each router
l Addresses of the multicast groups that interfaces at the host side of Router E statically join
in batches
Procedure
Step 1 Configure IPv6 addresses for interfaces on each router according to Figure 9-1. The

Step 2 Configure IS-IS IPv6 to make all router routable and set the costs of the routes to be the same.
# Configure Router A. Configurations on Routers B, C, D, and E are similar to those on
Router A and therefore their configuration details are not provided here.
[~RouterA-LoopBack0] pim ipv6 sm
[~RouterA-LoopBack0] commit
Step 4 Configure an RP on Router A.

# Configure loopback 0 on Router A as an RP.
[~RouterA] pim-ipv6
[~RouterA-pim6] c-bsr 2000::1
[~RouterA-pim6] c-rp 2000::1
Step 5 Configure stable-preferred IPv6 load splitting on Router E.

[~RouterE] multicast ipv6 load-splitting stable-preferred
[~RouterE] commit
Step 6 Configure the interfaces at the host side Router E to statically join multicast groups in batches.
# Configure GE 2/0/0 to statically join groups FF13::1 to FF13::3 in batches.
[~RouterE] interface gigabitethernet 2/0/0
[~RouterE-GigabitEthernet2/0/0] mld static-group ff13::1 inc-step-mask 128 number
3
[~RouterE-GigabitEthernet2/0/0] commit
[~RouterE-GigabitEthernet2/0/0] quit

# Multicast source (2001::1/64) sends multicast data to groups FF13::1 to FF13::3. Host A can
receive the multicast data from the multicast source. View brief information about the IPv6 PIM
routing table on Router E.
<RouterE> display pim ipv6 routing-table brief
Total 3 (*, G) entries; 3 (S, G) entries
00001.(*, FF13::1)
Upstream interface:Pos1/0/1
Number of downstream:1
00002.(2001::1, FF13::1)
00003.(*, FF13::2)

00004.(2001::1, FF13::2)
00005.(*, FF13::3)
00006.(2001::1, FF13::3)
(*, G) and (S, G) entries are distributed to the three equal-cost routes in balance, with the upstream
interfaces being POS 1/0/1, POS 1/0/2, and POS 1/0/3 respectively.
NOTE
The load splitting algorithm processes (*, G) and (S, G) entries separately and the process rules are the
same.
----End
Configuration Files
#
sysname RouterA
#
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
interface Pos2/0/1
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
interface Pos2/0/2
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
interface Pos2/0/3
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
interface LoopBack0
ipv6 enable

pim ipv6 sm
isis ipv6 enable 1
#
pim-ipv6
c-bsr 2000::1
c-rp 2000::1
#
return
#
sysname RouterB
#
#
isis 1
network-entity 10.0000.0000.0002.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
return
#
sysname RouterC
#
#
isis 1
network-entity 10.0000.0000.0003.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
return
#
sysname RouterD
#

#
isis 1
network-entity 10.0000.0000.0004.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
return

#
sysname RouterE
#
multicast ipv6 load-splitting stable-preferred
#
isis 1
network-entity 10.0000.0000.0005.00
#
undo shutdown
ipv6 enable
pim ipv6 sm
mld static-group FF13::1 inc-step-mask 128 number 3
isis ipv6 enable 1
#
interface Pos1/0/1
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
interface Pos1/0/2
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
interface Pos1/0/3
undo shutdown
link-protocol ppp
ipv6 enable
pim ipv6 sm
isis ipv6 enable 1
#
return


Configuration Guide - IP Multicast (V800R002C01 - 01) PDF

Загружено:

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

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

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

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

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

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

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

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

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

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

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

Configuration Guide - IP Multicast (V800R002C01 - 01) PDF

Загружено:

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

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

HUAWEI NetEngine5000E Core Router

Configuration Guide - IP Multicast

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2011-10-15) Huawei Proprietary and Confidential i

About This Document

Related Versions (Optional)

Product Name Version

HUAWEI NetEngine5000E V800R002C01

Indicates a hazard with a high level of risk, which if not

Indicates a hazard with a medium or low level of risk, which

Issue 01 (2011-10-15) Huawei Proprietary and Confidential ii

Indicates a potentially hazardous situation, which if not

Provides additional information to emphasize or supplement

Command Conventions (Optional)

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

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

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

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

2.8.2 Example for Configuring IGMP SSM Mapping.....................................................................................36

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

3.10.1 Example for Configuring PIM-SM Intra-domain Multicast..................................................................89

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

5.5.1 Summarizing Local MBGP Routes.......................................................................................................178

6 IP Multicast Routing Management........................................................................................212

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

7.3.1 Enabling IPv6 Multicast Routing..........................................................................................................240

8 IPv6 PIM Configuration...........................................................................................................269

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

8.6 Configuring IPv6 PIM-SSM...........................................................................................................................292

9 IPv6 Multicast Routing Management....................................................................................325

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

About This Chapter

1.1 IP Multicast Overview

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

1.1 IP Multicast Overview

Basic Concepts of Multicast

IPv4 Multicast Addresses

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 2

Table 1-1 Range and description of IPv4 multicast addresses

224.0.2.0 to The addresses in this range are Any-Source Multicast (ASM)

232.0.0.0 to The addresses in this range are Source-Specific Multicast

239.0.0.0 to The addresses in this range are administration multicast

IPv4 Multicast Protocols

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 3

Figure 1-1 Application position of each IPv4 multicast protocol

IPv4 Network IPv4 Network

Table 1-2 IPv4 multicast protocols

Internet Group Between hosts Connecting hosts to a multicast network:

Protocol Independent Between intra- Guiding multicast routing and forwarding:

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 4

Multicast Protocol Application Function

Multicast Source Between inter- Sharing the information of inter-domain

1.2 Typical Configuration Scheme