HUAWEI NetEngine40E/80E Universal Service

Router
V600R006C00

Troubleshooting - IP Multicast

Issue 03
Date 2013-08-20

HUAWEI TECHNOLOGIES CO., LTD.

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

Trademarks and Permissions

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

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China

Website: http://www.huawei.com
Email: [email protected]

Issue 03 (2013-08-20) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast About This Document

About This Document

Purpose
NOTE

l This document takes interface numbers and link types of the NE40E-X8 as an example. In working
situations, the actual interface numbers and link types may be different from those used in this
document.
l On NE80E/40E series excluding NE40E-X1 and NE40E-X2, line processing boards are called Line
Processing Units (LPUs) and switching fabric boards are called Switching Fabric Units (SFUs). On
the NE40E-X1 and NE40E-X2, there are no LPUs and SFUs, and NPUs implement the same functions
of LPUs and SFUs to exchange and forward packets.

This document describes how to troubleshoot the services of the HUAWEI NetEngine80E/
40E in terms of common faults and causes, troubleshooting cases, and FAQs.

This document describes the procedure and method for troubleshooting for the HUAWEI
NetEngine80E/40E.

CAUTION
Note the following precautions:
l Currently, the device supports the AES and SHA2 encryption algorithms. AES is reversible,
while SHA2 is irreversible. A protocol interworking password must be reversible, and a local
administrator password must be irreversible.
l If the plain parameter is specified, the password will be saved in plaintext in the configuration
file, which has a high security risk. Therefore, specifying the cipher parameter is
recommended. To further improve device security, periodically change the password.
l Do not set both the start and end characters of a password to "%$%$." This causes the
password to be displayed directly in the configuration file.

Related Versions
The following table lists the product versions related to this document.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential ii

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast About This Document

Product Name Version

HUAWEI NetEngine80E/40E V600R006C00

Router

Intended Audience
This document is intended for:

l System maintenance engineers

l Commissioning engineers
l Network monitoring engineers

Symbol Conventions
The symbols that may be found in this document are defined as follows.

Symbol Description

DANGER indicates a hazard with a high level or medium

level of risk which, if not avoided, could result in death or
DANGER
serious injury.

WARNING indicates a hazard with a low level of risk which,

if not avoided, could result in minor or moderate injury.
WARNING

CAUTION indicates a potentially hazardous situation that,

CAUTION if not avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
TIP TIP indicates a tip that may help you solve a problem or save
time.

NOTE NOTE provides additional information to emphasize or

supplement important points of the main text.

Command Conventions
The command conventions that may be found in this document are defined as follows.

Convention Description

Boldface The keywords of a command line are in boldface.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential iii

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast About This Document

Convention Description

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
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.

Changes in Issue 03 (2013-08-20)

The third commercial release.

Changes in Issue 02 (2013-04-15)

The second commercial release.

Changes in Issue 01 (2012-11-10)

Initial commercial release.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential iv

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast Contents

Contents

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

1 Layer 2 Multicast Troubleshooting............................................................................................1
1.1 Layer 2 Multicast Traffic Cannot Be Transmitted.........................................................................................................2
1.1.1 Common Causes..........................................................................................................................................................2
1.1.2 Troubleshooting Flowchart..........................................................................................................................................2
1.1.3 Troubleshooting Procedure..........................................................................................................................................3
1.1.4 Relevant Alarms and Logs..........................................................................................................................................5

2 L3 Multicast....................................................................................................................................6
2.1 Multicast Traffic Cannot Be Transmitted.......................................................................................................................7
2.1.1 Common Causes..........................................................................................................................................................7
2.1.2 Troubleshooting Flowchart..........................................................................................................................................7
2.1.3 Troubleshooting Procedure..........................................................................................................................................8
2.1.4 Relevant Alarms and Logs..........................................................................................................................................9
2.2 The PIM Neighbor Relationship Remains Down...........................................................................................................9
2.2.1 Common Causes..........................................................................................................................................................9
2.2.2 Troubleshooting Flowchart........................................................................................................................................10
2.2.3 Troubleshooting Procedure........................................................................................................................................11
2.2.4 Relevant Alarms and Logs........................................................................................................................................12
2.3 The RPT on a PIM-SM Network Fails to Forward Data..............................................................................................12
2.3.1 Common Causes........................................................................................................................................................12
2.3.2 Troubleshooting Flowchart........................................................................................................................................12
2.3.3 Troubleshooting Procedure........................................................................................................................................14
2.3.4 Relevant Alarms and Logs........................................................................................................................................17
2.4 The SPT on a PIM-SM Network Fails to Forward Data..............................................................................................17
2.4.1 Common Causes........................................................................................................................................................17
2.4.2 Troubleshooting Flowchart........................................................................................................................................17
2.4.3 Troubleshooting Procedure........................................................................................................................................19
2.4.4 Relevant Alarms and Logs........................................................................................................................................22
2.5 MSDP Peers Cannot Generate Correct (S, G) Entries..................................................................................................22
2.5.1 Common Causes........................................................................................................................................................22
2.5.2 Troubleshooting Flowchart........................................................................................................................................23
2.5.3 Troubleshooting Procedure........................................................................................................................................25

Issue 03 (2013-08-20) Huawei Proprietary and Confidential v

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast Contents

2.5.4 Relevant Alarms and Logs........................................................................................................................................27

2.6 An MDT Fails to Be Established in a Multicast VPN..................................................................................................27
2.6.1 Common Causes........................................................................................................................................................27
2.6.2 Troubleshooting Flowchart........................................................................................................................................27
2.6.3 Troubleshooting Procedure........................................................................................................................................29
2.6.4 Relevant Alarms and Logs........................................................................................................................................33
2.7 The Multicast Device Cannot Generate IGMP Entries or MLD Entries......................................................................33
2.7.1 Common Causes........................................................................................................................................................33
2.7.2 Troubleshooting Flowchart........................................................................................................................................33
2.7.3 Troubleshooting Procedure........................................................................................................................................35
2.7.4 Relevant Alarms and Logs........................................................................................................................................37
2.8 Related Troubleshooting Cases....................................................................................................................................38
2.8.1 The IPTV Screen Freezes Up Due to the Low Performance of a Downstream Device............................................38
2.8.2 The IPTV Screen Messes Up Due to Uneven Eth-Trunk Load Balancing...............................................................40
2.8.3 IPTV Services Are Interrupted Because an Invalid Dynamic RP Is Elected............................................................43
2.8.4 IPTV Channels Are Lost Because PIM Is Not Configured.......................................................................................45
2.8.5 The IPTV Has Sound but No Picture Due to Incorrect ACL Configurations...........................................................47
2.8.6 Certain Channels Are Unavailable Because the Router at the Source Side Is Not Enabled with a Multicast Protocol
on the IPTV Network.........................................................................................................................................................48
2.8.7 Receivers Attached to a Multicast Interface Experience Video Lagging..................................................................50
2.8.8 A Multicast Router Fails to Process BSR Messages Because the RPF Check Fails.................................................52
2.8.9 Users on an IP MAN Fail to Receive IPTV Programs..............................................................................................54
2.8.10 PIM Inter-Domain MSDP Failed............................................................................................................................56
2.8.11 Multicast Traffic Failed to Be Transmitted Because MTUs on Two Link Ends Are Inconsistent.........................57
2.8.12 A PE in a Multicast VPN in BGP A-D Mode Cannot Learn A-D Routing Information from Remote Peers.........59
2.8.13 A PIM Neighbor Relationship Cannot Be Established in a Multicast VPN in BGP A-D Mode Because the Configured
Share-Group Address Is Beyond the SSM Group Address Range.....................................................................................60
2.8.14 A Receiver on a Multicast VPN Extranet-enabled Network Cannot Receive Multicast Data from a Source VPN
............................................................................................................................................................................................62

Issue 03 (2013-08-20) Huawei Proprietary and Confidential vi

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 1 Layer 2 Multicast Troubleshooting

1 Layer 2 Multicast Troubleshooting

About This Chapter

1.1 Layer 2 Multicast Traffic Cannot Be Transmitted

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 1

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 1 Layer 2 Multicast Troubleshooting

1.1 Layer 2 Multicast Traffic Cannot Be Transmitted

1.1.1 Common Causes

This fault is commonly caused by one of the following causes:

l A fault occurs on the uplink or downlink.

l The VLAN or VSI status is incorrect.
l No forwarding entry is established due to incorrect Layer 2 multicast CAC configurations.
l The number of Layer 2 multicast entries on the device reaches the upper limit.
l Traffic interruption caused by a hardware failure, such as board failure, or improper
connection of optic fiber or network cable.

1.1.2 Troubleshooting Flowchart

After Layer 2 multicast is configured, multicast traffic cannot be transmitted.

The troubleshooting roadmap is as follows:

l Check that the link functions properly.
l Check that configurations are correct.
l Check that the number of Layer 2 multicast entries on the device is within the upper limit.

Figure 1-1 shows the troubleshooting flowchart.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 2

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 1 Layer 2 Multicast Troubleshooting

Figure 1-1 Troubleshooting flowchart for the fault that Layer 2 multicast traffic cannot be
transmitted

Seek technical support

Multicast
traffic cannot
be transmitted
No

Yes
Forwarding
Interface No
Yes Layer 2 entries cannot be
Status is multicast CAC is generated due to Layer
normal? configured? 2 multicast CAC
configurations?
No
No
Yes
Check and rectify Number of
the fault on the Layer 2 multicast
uplink or downlink entries on the device
reaches the upper Yes
limit?
IGMP Yes
No
Is fault Snooping is
rectified? enabled in the VLAN
or VSI?
No
Yes End

Function of
discarding unknown No
Modify CAC
multicast traffic is
configurations
enabled?

Yes
No
Correct the Seek technical Is fault
configuration support rectified?

Yes

End

1.1.3 Troubleshooting Procedure

Context
NOTE

Saving the results of each troubleshooting step is recommended. If troubleshooting fails to correct the fault,
a record of the actions taken will exist to provide to Huawei technical support personnel.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 3

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 1 Layer 2 Multicast Troubleshooting

Procedure
Step 1 Check that the uplink and downlink interfaces are Up.

Run the display this interface command on the interface enabled with the multicast function
to check whether the interface is Down.

l If the interface is shut down, run the undo shutdown command on the interface.
l If the interface is restarted but it is still in the Down state, check whether the physical link
is faulty.
l If the interface is in the Up state but the fault persists, go to Step 2.

Step 2 Check that IGMP snooping is enabled in the VLAN or VSI.

Run the display igmp-snooping configuration command. If igmp-snooping enable is

displayed, IGMP snooping is enabled.

NOTE

In this command, you can specify the parameter vsi vsi-name or vlan vlan-id to check IGMP snooping
configurations in the specified VSI or VLAN.
l If IGMP snooping is disabled, check whether the function of discarding unknown multicast
traffic is enabled in the VLAN or VSI view.
NOTE

The unknown-multicast discard command is configured in the VLAN view to discard unknown
multicast traffic; the unknown-frame multicast drop command is configured in the VSI view to
discard unknown multicast traffic.
If either of the preceding commands is used to enable the function of discarding
unknown multicast traffic:
Run the undo unknown-multicast discard command in the VLAN view or the
unknown-frame multicast broadcast command in the VSI view to disable the function
of discarding unknown multicast traffic.
If neither of the preceding commands is used to enable the function of discarding
unknown multicast traffic but the fault persists:
Contact Huawei technical support personnel.
l If IGMP snooping is enabled but the fault persists, go to Step 3.

Step 3 Check that the number of Layer 2 multicast entries on the device is below the upper limit.

Run the display igmp-snooping port-info command on the device to check the number of Layer
2 multicast entries.

l If the number of Layer 2 multicast entries has exceeded the upper limit, no more multicast
entries can be generated.
NOTE

The specification of Layer 2 multicast entries varies with the software version. For detailed
information, see descriptions of specifications of each version.
l If the number of Layer 2 multicast entries is below the upper limit but the fault persists, go
to Step 4.

Step 4 Check that Layer 2 multicast CAC is properly configured.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 4

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 1 Layer 2 Multicast Troubleshooting

Run the display l2-multicast limit command on the device to check Layer 2 multicast CAC
configurations and statistics.

l If the CAC statistics have reached the configured CAC limit, adjust the configured CAC
limit as required so that entries of new multicast groups can be generated. Run the display
igmp-snooping port-info command to check whether Layer 2 multicast protocol entries
are generated.
NOTE

In addition to running the display l2-multicast limit command to check whether the CAC statistics
reach the configured CAC limit, you can enter the Layer 2 multicast global channel, VLAN-based
channel, or VSI-based channel view to check whether the unspecified-channel deny command is
configured. If this command is configured and the required multicast group is unspecified, the
multicast group cannot join the channel.
l If Layer 2 multicast CAC is not configured but the fault persists, contact Huawei technical
support personnel.

Step 5 Collect the following information and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure
l Configuration files, log files, and alarm files of the device

----End

1.1.4 Relevant Alarms and Logs

Relevant Alarms
None.

Relevant Logs
None.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 5

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2 L3 Multicast

About This Chapter

2.1 Multicast Traffic Cannot Be Transmitted

2.2 The PIM Neighbor Relationship Remains Down

2.3 The RPT on a PIM-SM Network Fails to Forward Data

2.4 The SPT on a PIM-SM Network Fails to Forward Data

2.5 MSDP Peers Cannot Generate Correct (S, G) Entries

2.6 An MDT Fails to Be Established in a Multicast VPN

2.7 The Multicast Device Cannot Generate IGMP Entries or MLD Entries

2.8 Related Troubleshooting Cases

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 6

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2.1 Multicast Traffic Cannot Be Transmitted

2.1.1 Common Causes

This fault is commonly caused by one of the following causes:

l Route configurations are incorrect.

l The VLAN or VSI status is incorrect.
l Multicast configurations fail to be delivered.
l No Layer 2 multicast entry is generated.
l No upper-layer forwarding entry is generated.

2.1.2 Troubleshooting Flowchart

After Layer 3 multicast is enabled, multicast traffic cannot be transmitted.

The troubleshooting roadmap is as follows:

l Check that the route to the multicast source is reachable.
l Check that the configuration for enabling multicast has been delivered to interface boards.
l Check that PIM information table has been generated.
l Check that forwarding entries have been generated.

Figure 2-1 shows the troubleshooting flowchart.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 7

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-1 Troubleshooting flowchart for the fault that multicast traffic cannot be transmitted
Multicast traffic
Cannot be
transmitted

Route to the No Configure a static route Yes

Is fault
multicast source is to the multicast source or
rectified?
reachable? enable a routing protocol
No
Yes

Configurations No
Seek technical
Have been delivered to End
support
interface boards?

Yes

PIM information No
table has been
generated?

Yes

Check whether forwarding

entries have been generated
and record the phenomena

2.1.3 Troubleshooting Procedure

Context
NOTE

Saving the results of each troubleshooting step is recommended. If troubleshooting fails to correct the fault,
a record of the actions taken will exist to provide to Huawei technical support personnel.

Procedure
Step 1 Check that the route to the multicast source is reachable.

Run the display ip routing-table ip-address command on the device to check whether the
routing table contains a route to the multicast source.

NOTE

ip-address specifies the address of the multicast source.

l If no route to the multicast source is found, check route configurations.
l If the route to the multicast source is reachable but the fault persists, go to Step 2.

Step 2 Check that the configuration for enabling multicast has been delivered to interface boards.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 8

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Run the display multicast forwarding-table statistics and display multicast forwarding-
table statistics slot slot-number commands on the device to check whether the configuration
for enabling multicast has been delivered to interface boards.

l If no information about the maximum number of multicast entries and outbound interfaces
is displayed, no multicast configuration is delivered to the interface board. In this case,
contact Huawei technical support personnel.
For example:
<HUAWEI>display multicast forwarding-table slot 1
Total 0 entry matched

l If multicast configurations have been delivered to interface boards but the fault persists, go
to Step 4.

Step 3 Check that PIM information table has been generated.

Run the display pim routing-table and display multicast routing-table commands on the
device to check whether PIM information table has been generated.

l If no upper-layer protocol entry is displayed, contact Huawei technical support personnel.

l If upper-layer protocol entries are displayed but the fault persists, go to Step 5.

Step 4 Check that forwarding entries have been generated.

Run the display multicast forwarding-table and display multicast forwarding-table slot slot-
number commands on the device to check whether forwarding entries have been generated.

l If forwarding entries have been generated but the fault persists, record the displayed
information and contact Huawei technical support personnel.

Step 5 Collect the following information and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure
l Configuration files, log files, and alarm files of the device

----End

2.1.4 Relevant Alarms and Logs

Relevant Alarms
None.

Relevant Logs
None.

2.2 The PIM Neighbor Relationship Remains Down

2.2.1 Common Causes

This fault is commonly caused by one of the following causes:

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 9

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

l The interface is physically Down or the link-layer protocol status of the interface is Down.
l PIM is not enabled on the interface.
l PIM configurations on the interface are incorrect.

2.2.2 Troubleshooting Flowchart

After PIM network configuration is complete, the PIM neighbor relationship remains Down.

Figure 2-2 shows the troubleshooting flowchart.

Figure 2-2 Troubleshooting flowchart: the PIM neighbor relationship remains Down
The PIM neighbor
relationship remains
Down

Is PIM enabled No Yes

Enable PIM on the interface Is fault rectified?
on the interface?

Yes No

No No Refer to the
Is the PIM status Is the interface
troubleshooting of
Up on the interface? physically Up?
interface Down

Yes Yes
No Yes
Is fault rectified?

Yes No Refer to the

Is the link status Up
troubleshooting of
on the interface?
interface Down

No Yes
Is fault rectified?

Are the PIM No Change the PIM Yes

configurations on the configurations on the Is fault rectified?
interface correct? interface

Yes No

Seek technical support End

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 10

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2.2.3 Troubleshooting Procedure

Context
NOTE

Saving the results of each troubleshooting step is recommended. If troubleshooting fails to correct the fault,
a record of the actions taken will exist to provide to Huawei technical support personnel.

Procedure
Step 1 Check that PIM is enabled on the interface.

Run the display current-configuration interface interface-type interface-number command to

check whether PIM is enabled on the interface.

l If PIM is not enabled, enable PIM on the interface.

If "Error: Please enable multicast in the system view first." is prompted when you enable
PIM, first run the multicast routing-enable command in the system view to enable the
multicast function. Then, go on to enable PIM-SM or PIM-DM on the interface.
l If PIM has been enabled on the interface, go to Step 2.

Step 2 Check that the PIM status of the interface is Up.

Run the display pim interface interface-type interface-number command to check whether the
PIM status of the interface is Up.

l If the PIM status is Down, run the display interface interface-type interface-number
command to check whether the physical status and link status of the interface are both Up.
1. If the physical status is not Up, make the physical status go Up.
2. If the link status is not Up, make the link status go Up.
l If the PIM status of the interface is Up, go to Step 3.

Step 3 Check that PIM configurations on the interface are correct.

This fault may be caused by the following PIM configurations:

l The IP addresses of directly-connected interfaces are on different network segments.
l PIM silent is configured on the interface.
l A PIM neighbor filtering policy is configured on the interface and the address of the PIM
neighbor is filtered out by the policy.
l If the interface is configured to deny Hello messages without Generation IDs, the interface
discards all the Hello messages received from PIM neighbors without any Generation IDs.
As a result, the PIM neighbor relationship cannot go Up. This case applies to the scenario in
which Huawei devices are intercommunicating with non-Huawei devices.

Run the display current-configuration interface interface-type interface-number command to

check whether any of the preceding PIM configurations exist on the interface.

l If any of the preceding PIM configurations exist, correct it.

l If the fault persists after the preceding operations are complete, go to Step 4.

Step 4 Collect the following information and contact Huawei technical support personnel.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 11

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

l Results of the preceding troubleshooting procedure

l Configuration files, log files, and alarm files of the device

----End

2.2.4 Relevant Alarms and Logs

Relevant Alarms
None.

Relevant Logs
PIM/4/NBR_DOWN

2.3 The RPT on a PIM-SM Network Fails to Forward Data

2.3.1 Common Causes

This fault is commonly caused by one of the following causes:

l The unicast route from the multicast device to the RP is unavailable.

l The RP addresses on multicast devices are inconsistent.
l The downstream interface on the multicast device does not receive any (*, G) Join
messages.
l PIM-SM is not enabled on interfaces.
l The RPF route to RP is incorrect, for example, the unicast route contains a loop.
l Configurations are incorrect, for example, the configurations of the TTL, MTU, or multicast
boundary are improper.

2.3.2 Troubleshooting Flowchart

After a PIM-SM network is configured, the RPT cannot forward data.

Figure 2-3 shows the troubleshooting flowchart.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 12

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-3 Troubleshooting flowchart: the RPT on a PIM-SM network fails to forward data
The RPT on a PIM-SM network
fails to forward data Check next hop along
Re-check RPF path from the
receiver's DR to RP No
the DR
Ensure Yes Seek
Do correct (*, G) Yes
That the current router technical
entries exist?
is an RP? support
No

Has the
downstream interface No Is fault Yes
Rectify the interface fault
received Join rectified?
messages?
Yes No

Is PIM-SM No Enable PIM-SM on Is fault Yes

enabled on interfaces? interfaces rectified?
Yes No

Are RP No Yes
Rectify the faults on the Is fault
configurations
static RP or BSR RP rectified?
correct?
Yes No

Is the RPF route No Rectify the fault of unicast Is fault Yes

to the RP available? routes rectified?

Yes No

No Is the
interface that forwards
multicast data the
receiver's DR?

Yes

Is the Change the outbound

outbound interface of the Yes interface of the RPF route Is fault Yes
RPF route to the RP a TE to the RP, ensuring that it is rectified?
tunnel interface? not a TE tunnel interface
No No

Is a multicast Yes Yes

Remove the configurations Is fault
boundary configured on the
of the multicast boundary rectified?
interface?
No No
Remove the configurations
Yes of the source-policy or Is fault Yes
Is a source-policy
configured? change the configurations rectified?
of the ACL
No
No

Do correct (*, G) Yes

entries exist?
No
End
Seek technical support

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 13

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2.3.3 Troubleshooting Procedure

Procedure
Step 1 Check that the PIM routing table contains the correct (*, G) entries.

Run the display pim routing-table group-address command on the device to check whether
the PIM routing table contains the correct (*, G) entries. Focus on checking whether the
downstream interface list contains downstream interfaces to forward data to all (*, G) group
members.

l If the (*, G) entries exist and are all correct in the PIM routing table, run the display
multicast forwarding-table group-address command every 15 seconds to check whether
the forwarding table contains (S, G) entries associated with the (*, G) entries and whether
the value of the Matched field in the command output continues to increase.
If the forwarding table contains associated (S, G) entries and the value of the
Matched field continues to increase, the upstream device can normally forward
multicast data to the current device but the current device fails to forward the data
downstream, for example, a too small TTL value or a forwarding fault.
If the forwarding table does not contain the associated (S, G) entries or the value of the
Matched field remains unchanged, do as follows:
If the current device is not an RP, the current device has not received any multicast
data. This fault may be caused by the upstream device. Then check whether the PIM
routing table on the upstream device contains correct (S, G) entries.
If the current device is already an RP, it indicates the RPT has been set up but the
RP fails to receive the multicast data from the multicast source. This fault may be
caused by a failure in source's DR registration. In such a case, contact Huawei
technical support personnel.
l If the PIM routing table does not contain correct (*, G) entries, go to Step 2.

Step 2 Check that the downstream interface has received Join messages.

Run the display pim control-message counters interface interface-type interface-number

message-type join-prune command to check whether the number of received Join/Prune
messages on the downstream interface continues to increase.

l If the number of received Join/Prune messages on the downstream interface does not
increase, run the display pim control-message counters interface interface-type
interface-number message-type join-prune command on the downstream device to check
whether the downstream device has sent Join/Prune messages upstream.
If the command output shows that the number of sent Join/Prune messages continues
to increase, the downstream device has sent Join/Prune messages. This fault may be
caused by a failure in PIM neighbor communication. In such a case, contact Huawei
technical support personnel.
If the command output shows that the number of sent Join/Prune messages does not
increase, the downstream device experiences a fault. Then locate the fault.
l If the number of received Join/Prune messages on the downstream interface continues to
increase, go to Step 3.

Step 3 Check that PIM-SM is enabled on interfaces.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 14

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

The following interfaces are easy to be ignored in enabling PIM-SM:

l RPF neighboring interface to the RP
l RPF interface to the RP
l Interface directly connected to shared network segment of user hosts, that is, downstream
interface of the receiver's DR

Run the display pim interface verbose command to check PIM configurations on the interface.
Focus on checking whether PIM-SM is enabled on the preceding interfaces.

l If the command output does not contain information about an interface on the device or the
PIM mode of an interface is dense, run the pim sm command on the interface.
If the system displays "Error: Please enable multicast in the system view first." when you
configure PIM-SM on the interface, run the multicast routing-enable command in the
system view to enable the multicast function first and enable PIM-SM on the interface.
l If PIM-SM has been enabled on all the interfaces on the device, go to Step 4.

Step 4 Check that the RP information is correct.

Run the display pim rp-info command on the device to check whether the device has learned
information about the RP serving a specific group and whether the RP information of the same
group on all other devices is consistent.

l If no RP information is displayed or RP information on the devices are inconsistent, do as

follows:
If the static RP is used on the network, run the static-rp command on all the devices to
make information about the RP serving a specific group consistent.
If the dynamic RP is used, contact Huawei technical support personnel.
l If RP information of a specific group is consistent on all the devices, go to Step 5.

Step 5 Check that an RPF route to the RP is available.

Run the display multicast rpf-info source-address command on the device to check whether
there is an RPF route to the RP.

l If the command output does not contain an RPF route to the RP, check the configurations
of unicast routes. Run the ping command on the device and the RP to check whether they
can ping each other successfully.
l If the command output shows an RPF route to the RP, do as follows:
If the command output shows that the RPF route is a static multicast route or an MBGP
route, run the display current-configuration command to check whether the static
multicast route or the MBGP route is properly configured.
If the command output shows that the RPF route is a unicast route, run the display ip
routing-table command to check whether the unicast route is consistent with the RPF
route.
l If the command output shows an RPF route to the RP and the route is properly configured,
go to Step 6.

Step 6 Check that the interface that forwards multicast data is a receiver's DR.

Run the display pim interface interface-type interface-number command on the device to check
whether the interface that forwards multicast data is a receiver's DR.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 15

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

l If the DR information in the command output is not marked local, troubleshoot the involved
DR following the preceding steps.
l If the DR information in the command output is marked with local, go to Step 7.

Step 7 Check whether the outbound interface of the RPF route to the RP is a TE tunnel interface.

Run the display multicast rpf-info source-address command on the device to check whether
the outbound interface of the RPF route to the RP is a TE tunnel interface.

The multicast routing is reverse to unicast routing. The TE tunnel is unidirectional and hence it
does not support multicast.

l If the command output shows that the outbound interface of the RPF route is a TE tunnel
interface, enable the local MT feature or change the configurations of the static multicast
route to ensure that the outbound interface of the RPF interface is not a TE tunnel interface.
l If the command output shows that the outbound interface of the RPF route is not a TE tunnel
interface, go to Step 8.

Step 8 Check whether a multicast boundary is configured on the interface.

Run the display current-configuration interface interface-type interface-number command

on the device to check whether a multicast boundary is configured on the interface.

l If the configuration of the interface contains multicast boundary, a multicast boundary is

configured on the interface. Then run the undo multicast boundary { group-address
{ mask | mask-length } | all command to delete the configuration of the multicast boundary
or re-plan the network to ensure that no multicast boundary is configured on the RPF
interface or the RPF neighboring interface.
l If no multicast boundary is configured on the interface, go to Step 9.

Step 9 Check whether a source policy is configured.

Run the display current-configuration configuration pim command to view the current
configurations in the PIM view.

l If the configuration contains source-policy acl-number, it indicates a source-based

filtering rule is configured. If the received multicast data is blocked by the ACL rule, the
multicast data is discarded. Then run the undo source-policy command to delete the
configuration of the ACL rule or reconfigure an ACL rule to ensure that the multicast data
can be normally forwarded.
l If no source policy is configured, go to Step 10.

Step 10 Check whether the PIM routing table contains the correct (*, G) entries.

Run the display pim routing-table group-address command on the device to check whether
the PIM routing table contains the correct (*, G) entries. For details, see Step 1.

If the fault persists after the preceding troubleshooting procedures are complete, contact Huawei
technical support personnel.

----End

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 16

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2.3.4 Relevant Alarms and Logs

Relevant Alarms
None.

Relevant Logs
None.

2.4 The SPT on a PIM-SM Network Fails to Forward Data

2.4.1 Common Causes

This fault is commonly caused by one of the following causes:

l The downstream interface on the multicast device does not receive any (S, G) Join
messages.
l PIM-SM is not enabled on the interface.
l The RPF route to the multicast source is incorrect. For example, the unicast route contains
a loop.
l Configurations are incorrect. For example, the configurations of the TTL, MTU, switchover
threshold, or multicast boundary are improper.

2.4.2 Troubleshooting Flowchart

After the PIM-SM network is configured, the SPT fails to forward data.

Figure 2-4 shows the troubleshooting flowchart.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 17

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-4 Troubleshooting flowchart: the SPT on a PIM-SM network fails to forward data
The RPT on a PIM-SM
network fails to forward data Check the next hop along the
RPF path from the receiver's
Re-check DR to the multicast source
the DR No
Yes Ensure Yes
Do correct (*, G) entries Seek technical
that the current router is
exist? support
an RP
No

Has the
downstream interface Is fault Yes
received Join messages? Rectify the interface fault
rectified?
No
No
Yes

No Is fault Yes
Is PIM-SM enabled Enable PIM-SM on interfaces
on interfaces? rectified?
Yes No

Is the RPF
No Rectify the fault of unicast Yes
route to the multicast Is fault rectified?
source available? routes

Yes No

Is the interface
No that forwards multicast
data the receiver's DR?

Yes

Is the
outbound interface Yes Change the outbound interface
of the RPF route to the RP of the RPF route to the Yes
Is fault rectified?
a TE tunnel interface? multicast source, ensuring that
it is not a TE tunnel interface

No
No

Is a multicast boundary Yes Remove the configurations of Is fault Yes

configured on the the multicast boudnary rectified?
interface?
No No

Yes Remove the configurations of the Yes

Is a source-policy Is fault
source-policy or change the
configured? rectified?
configurations of the ACL

No No

Yes
Do correct (*, G) entries
exist?
No End

Seek technical support

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 18

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2.4.3 Troubleshooting Procedure

Procedure
Step 1 Check that the PIM routing table contains the correct (S, G) entries.

Run the display pim routing-table command on the device to check whether the PIM routing
table contains the correct (S, G) entries.

l If the PIM routing table contains the correct (S, G) entries, do as follows:
Check whether the entry has an SPT flag.
If the multicast group is in the ASM group address range, the SPT switchover is
triggered by the RP, and the upstream interface of the RP is a register interface, the
RP has received the Register message from the source's DR but the SPT fails to be
established. Then contact Huawei technical support personnel.
If the multicast group is in the ASM group address range, the SPT switchover is
triggered by the receiver's DR, and the upstream interface is an RPF interface to the
RP but not the SPT interface to the multicast source, the SPT fails to be established.
Then run the display current-configuration configuration pim command on the
receiver's DR to view the current configurations in the PIM view. If the command
output shows spt-switch-threshold traffic-rate or spt-switch-threshold infinity,
run the undo spt-switch-threshold command to delete the configurations of the
traffic rate or run the spt-switch-threshold traffic-rate command to reconfigure a
proper traffic rate.
Check whether the downstream interface list contains downstream interfaces to forward
data to all group members.
If the (S, G) entries exist and are all correct in the PIM routing table, run the display
multicast forwarding-table command to view the (S, G) entries in the forwarding
table and check whether the value of the Forwarded field in the command output
continues to increase. The value of the Matched field is not updated in time.
Therefore, wait for several minutes after running the display multicast forwarding-
table command.
If the value of the Matched field continues to increase, the upstream device can
normally forward multicast data to the current device but the current device fails
to forward the data downstream. Then contact Huawei technical support
personnel.
If the value of the Matched field remains unchanged, do as follows:
If the current device is not a source's DR, the current device has not received
any multicast data. This fault may be caused by the upstream device. Then
check whether the PIM routing table on the upstream device contains correct
(S, G) entries.
If the PIM routing table on the upstream device does not contain the correct
(S, G) entries, troubleshoot the upstream device following the preceding
steps.
If the PIM routing table on the upstream device contains correct (S, G)
entries, but the value of the Matched field still remains unchanged,
contact Huawei technical personnel.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 19

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

If the current device is already a source's DR, SPT has been set up but the
source's DR fails to forward the multicast data along the SPT. Then contact
Huawei technical support personnel.
l If the PIM routing table does not contain the correct (S, G) entries, go to Step 2.

Step 2 Check that the downstream interface has received Join messages.
NOTE

If the current device is a receiver's DR, skip this step.

If the downstream interface does not receive any (S, G) Join messages, the possible causes may
be as follows:
l A fault occurs on the downstream interface.
l PIM-SM is not enabled on the downstream interface.

Run the display pim control-message counters interface interface-type interface-number

message-type join-prune command to check whether the number of received Join/Prune
messages on the downstream interface continues to increase.

l If the number of received Join/Prune messages on the downstream interface does not
increase, run the display pim control-message counters interface interface-type
interface-number message-type join-prune command on the downstream device to check
whether it has sent Join/Prune messages upstream.
If the command output shows that the number of sent Join/Prune messages continues
to increase, the downstream device has sent Join/Prune messages. This fault may be
caused by a failure in PIM neighbor communication. In this a case, contact Huawei
technical support personnel.
If the command output shows that the number of sent Join/Prune messages does not
increase, the downstream device experiences a fault. Then locate the fault.
l If the number of received Join/Prune messages on the downstream interface continues to
increase, go to Step 3.

Step 3 Check that PIM-SM is enabled on interfaces.

The following interfaces are easily overlooked when PIM-SM is enabled:

l RPF neighboring interface to the multicast source
l RPF interface to the multicast source
NOTE

In PIM-SM network deployment, enabling the multicast function on all the devices on the network and
enabling PIM-SM on all the interfaces are recommended.

Run the display pim interface verbose command to check PIM configurations on the interface.
Focus on checking whether PIM-SM is enabled on the preceding interfaces.

l If the command output does not contain information about an interface on the device or the
PIM mode of an interface is dense, run the pim sm command on the interface.
If the system displays "Error: Please enable multicast in the system view first." when you
configure PIM-SM on the interface, run the multicast routing-enable command in the
system view to enable the multicast function first and run the pim sm command in the
interface view to enable PIM-SM on the interface.
l If PIM-SM has been enabled on all the interfaces on the device, go to Step 4.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 20

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Step 4 Check that an RPF route to the multicast source is available.

Run the display multicast rpf-info source-address command on the device to check whether
an RPF route to the multicast source exists.

l If the command output does not contain an RPF route to the RP, check the configurations
of unicast routes. Run the ping command on the device and the RP to check whether they
can ping each other successfully.
l If the command output shows an RPF route to the multicast source, do as follows:
If the command output shows that the RPF route is a static multicast route or an MBGP
route, run the display current-configuration command to check whether the static
multicast route or the MBGP route is properly configured.
If the command output shows that the RPF route is a unicast route, run the display ip
routing-table command to check whether the unicast route is consistent with the RPF
route.
l If the command output shows an RPF route to the RP and the route is properly configured,
go to Step 5.

Step 5 Check that the interface that forwards multicast data is a receiver's DR.

Run the display pim interface interface-type interface-number command on the device to check
whether the interface that forwards multicast data is a receiver's DR.

l If the DR information in the command output is not marked local, troubleshoot the involved
DR following the preceding steps.
l If the DR information in the command output is marked local, go to Step 6.

Step 6 Check whether the outbound interface of the RPF route is a TE tunnel interface.

Run the display multicast rpf-info source-address command on the device to check whether
the outbound interface of the RPF route to the multicast source is a TE tunnel interface.

The multicast routing is based on the RPF check but the TE tunnel is unidirectional. Therefore,
TE tunnels are not applicable to the multicast scenario.

l If the command output shows that the outbound interface of the RPF route is a TE tunnel
interface, enable the local MT feature or change the configurations of the static multicast
route to ensure that the outbound interface of the RPF interface is not a TE tunnel interface.
l If the command output shows that the outbound interface of the RPF route is not a TE tunnel
interface, go to Step 7.

Step 7 Check whether a multicast boundary is configured on the interface.

Run the display current-configuration interface interface-type interface-number command

on the device to check whether a multicast boundary is configured on the interface.

l If the configuration of the interface contains multicast boundary, a multicast boundary is

configured on the interface. Then run the undo multicast boundary { group-address
{ mask | mask-length } | all command to delete the configuration of the multicast boundary
or re-plan the network to ensure that no multicast boundary is configured on the RPF
interface or the RPF neighboring interface.
l If no multicast boundary is configured on the interface, go to Step 8.

Step 8 Check whether a source policy is configured.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 21

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Run the display current-configuration configuration pim command to view the current
configurations in the PIM view.

l If the configuration contains source-policy acl-number, a source filtering rule is

configured. If the received multicast data is blocked by the ACL rule, the multicast data is
discarded. Then run the undo source-policy command to delete the configuration of the
ACL rule or reconfigure an ACL rule to ensure that the multicast data can be normally
forwarded.
l If no source policy is configured, go to Step 9.

Step 9 Check whether the PIM routing table contains the correct (S, G) entries.

Run the display pim routing-table command on the device to check whether the PIM routing
table contains the (S, G) entries. For details, see Step 1.

If the fault persists after the preceding troubleshooting procedures are complete, contact Huawei
technical support personnel.

----End

2.4.4 Relevant Alarms and Logs

Relevant Alarms
None.

Relevant Logs
None.

2.5 MSDP Peers Cannot Generate Correct (S, G) Entries

2.5.1 Common Causes

This fault is commonly caused by one of the following causes:

l The MSDP peer to initiate SA messages is not configured on the RP.

l The logical RP is not configured on the devices to be deployed with anycast RP or
configurations of the logical RP are incorrect.
l MSDP peer relationships are not set up between every two members in a mesh group.
l The used intra-domain multicast protocol is not PIM-SM.
l The RPF route to the multicast source is incorrect. For example, the unicast route contains
a loop.
l Configurations are incorrect. For example, the configurations of the SA policy, import
policy, TTL, switchover threshold, or multicast boundary are improper.
l The SA message fails to pass RPF check.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 22

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2.5.2 Troubleshooting Flowchart

After configurations are complete on a multicast network, MSDP peers cannot generate correct
(S, G) entries.

Figure 2-5 shows the troubleshooting flowchart.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 23

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-5 Troubleshooting flowchart: MSDP peers cannot generate correct (S, G) entries
MSDP peers cannot generate
correct (S, G) entries

Ensure that interfaces

No are correctly configured Yes
Are MSDP Is fault
peers in the Up state? and peers are reachable rectified?
through unicast routes
Yes No

No Is fault Yes
Is SA cache enabled? Enable SA cache
rectified?

Yes No

Have any SA Yes Ensure that MSDP peers

Is fault Yes
messages reached can receive SA
rectified?
MSDP peers? messages
No No

Are export Yes Remove or change the

Is fault Yes
policies configured on MSDP configurations of the rectified?
peers? export policies
No No
Yes
Remove or change the Is fault
Are import policies Yes
configurations of the rectified?
configured on MSDP
import policies
peers?
No No

Does current
No MSDP peer receive multicast
data from the multicast
source?
Yes

Yes Change the

Is the current MSDP Is fault Yes
configurations of the RP
peer an RP? rectified?
or MSDP

No No

Are import-source Yes Remove or change the

policies configured on Is fault Yes
configurations of the
the current MSDP rectified?
import-source policies
peer? No
No

Seek technical support End

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 24

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2.5.3 Troubleshooting Procedure

Context
NOTE

Saving the results of each troubleshooting step is recommended. If troubleshooting fails to correct the fault,
a record of the actions taken will exist to provide to Huawei technical support personnel.

Procedure
Step 1 Check that the status of MSDP peers is Up.
Run the display msdp brief command on the devices setting up an MSDP peer relationship to
check whether the status of MSDP peers is Up.
l If the command output shows that the status of MSDP peers is Down, check whether the
MSDP peer interfaces are correctly configured and whether the MSDP peers can ping each
other successfully. If the ping fails, perform troubleshooting based on The Ping Operation
Fails.
l If the MSDP peers are both in the Up state, go to Step 2.
Step 2 Check that SA cache is enabled.
Run the display current-configuration configuration msdp command on MSDP peers to view
the current configurations in the MSDP view.
l If the command output shows undo cache-sa-enable, SA cache is disabled in the MSDP
view. In this case, run the cache-sa-enable command in the MSDP view to enable SA
cache.
l If SA cache has been enabled, go to Step 3.
Step 3 Check that SA messages have reached MSDP peers.
Run the display msdp sa-count command on MSDP peers to check the contents of the SA
cache.
l If there is no command output, contact Huawei technical support personnel.
l If the value of the Number of source or Number of group field in the command output
is non-zero, SA messages have reached the peers. Then go to Step 4.
Step 4 Check whether export policies are configured on the MSDP peers.
Run the display current-configuration configuration msdp command in the MSDP view on
the MSDP peers to view the current configurations.
l If export policies are configured on the MSDP peers, do as follows:
If the command output shows the configurations of the peer peer-address sa-policy
export command without any parameters, the MSDP peers are disabled from
forwarding messages received from the multicast source. Then run the undo peer peer-
address sa-policy export command to delete the configurations of export policies.
If the command output shows the configurations of the peer peer-address sa-policy
export acl advanced-acl-number command with an ACL specified, MSDP peers can
forward only the (S, G) entries permitted by the ACL. Then check whether ACL-related
commands are run on the MSDP peers and whether (S, G) entries are permitted by the

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 25

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

ACL. You can run the undo peer peer-address sa-policy export command to delete
the configurations of the ACL or change the configurations of the ACL rules.
l If no export policies are configured on MSDP peers, go to Step 5.

Step 5 Check whether import policies are configured on MSDP peers.

Run the display current-configuration configuration msdp command in the MSDP view on
the MSDP peers to view the current configurations.

l If import policies are configured on MSDP peers, do as follows:

If the command output shows the configurations of the peer peer-address sa-policy
import command without any parameters, the MSDP peers are disabled from receiving
messages from the multicast source. Run the undo peer peer-address sa-policy
import command to delete the export policy configurations.
If the command output shows the configurations of the peer peer-address sa-policy
import acl advanced-acl-number command with an ACL specified, MSDP peers can
receive only the (S, G) entries permitted by the ACL. Check whether ACL-related
commands are run on the MSDP peers and whether (S, G) entries are permitted by the
ACL. Run the undo peer peer-address sa-policy import command to delete the
configurations of the ACL or change the configurations of the ACL rule.
l If no import policies are configured on the MSDP peers, go to Step 6.

Step 6 Check whether the current MSDP peer receives multicast data from the multicast source.
l If the current MSDP peer does not receive multicast data from the multicast source,
troubleshoot the upstream device following the preceding steps.
l If the current MSDP peer receives multicast data from the multicast source, go to Step 7.

Step 7 Check whether the current MSDP peer is an RP.

Run the display pim routing-table command on the MSDP peer closest to the multicast source
to view the routing table.

l If the (S, G) entry does not have a 2MSDP flag, the MSDP peer is not an RP. Change the
configurations of the RP or MSDP peer on the PIM-SM network to ensure that the MSDP
peer is an RP.
l If the MSDP peer is an RP, go to Step 8.

Step 8 Check whether import-source policies are configured on the current MSDP peer.

The import-source [ acl acl-number ] command is used to enable an MSDP peer to filter the
(S, G) entries to be advertised based on source addresses when creating SA messages. The MSDP
peer can control the transmission of multicast source information. By default, SA messages can
be used to advertise information about all known multicast sources.

Run the display current-configuration configuration msdp command in the MSDP view on
the MSDP peer closest to the multicast source to view the current configurations.

l If import-source policies are configured on the MSDP peer, do as follows:

If the command output shows the configurations of the import-source command
without any parameters, the MSDP peer is disabled from advertising multicast source
information. Then run the undo import-source command to delete the import-source
policy configurations.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 26

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

If the command output shows the import-source acl acl-number command with an
ACL specified, the MSDP peer advertises only (S, G) information matching the ACL.
Then check whether ACL-related commands are run on the MSDP peer and whether
(S, G) entries are permitted by the ACL. Then run the undo import-source command
to delete the configurations of the ACL or change the configurations of the ACL rule.
l If no import policies are configured on the MSDP peers, go to Step 9.

Step 9 If the fault persists, collect the following information and contact Huawei technical support
personnel.
l Results of the preceding operation procedure
l Configuration files, log files, and alarm files of the device

----End

2.5.4 Relevant Alarms and Logs

Relevant Alarms
None.

Relevant Logs
None.

2.6 An MDT Fails to Be Established in a Multicast VPN

2.6.1 Common Causes

This fault is commonly caused by one of the following causes:

l PIM is not enabled on multicast tunnel interfaces (MTIs).

l The address of the MTI is different from the address used by a PE to set up an IBGP peer
relationship with its peer over the public network.
l The share-groups configured on the PEs bound to the same VPN instance are different.
l Filtering rules are configured for some addresses in the switch-group- pool.

2.6.2 Troubleshooting Flowchart

After configurations are complete on a multicast VPN, an MDT cannot be established.

Figure 2-6 shows the troubleshooting flowchart.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 27

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-6 Troubleshooting flowchart for the fault that an MDT fails to be established in a
multicast VPN
MDT fails to be established in
multicast VPN

Are unicast No Ensure routers are reachable Is fault Yes

routes available? through unicast routes rectified?
No
Yes

Ensure the TTL

Is TTL of No value of multicast data sent by Is fault Yes
multicast data sufficient from multicast source is sufficient to rectified?
source to destination? reach the destination

Yes No
Yes
No Ensure multicast is enabled on Is fault
Is multicast enabled? rectified?
both public network and VPNs
Yes No

Are the No Ensure share-group configuration Yes

Is fault
configurations of share-roups for the same VPN instance bound
rectified?
consistent? to PEs are consistent
No
Yes
Ensure MTI address is the address
Are MTIs correctly No Is fault Yes
to set up IBGP peer over the public
configured? rectified?
network
Yes No

Ensure all interfaces on public

Are PIM neighbor No
network or all interfaces in each Is fault Yes
relationship successfully
VPN are configured with the same rectified?
established?
PIM protocol
No
Yes

Are the BSR Yes Ensure the BSR and RP are Is fault Yes
and the RP correctly
correctly configured rectified?
configured?
No
No

Are the Yes Yes

configured SSM group Ensure SSM group address Is fault
address ranges ranges are correctly configured rectified?
consistent?
No
No
Ensure RPF interface Yes
Is multicast Yes Is fault
Is not configured
boundary configured? rectified?
with multicast boundary
No No
No Yes
Is IGMP Is fault
correctly configured? See IGMP Troubleshooting
rectified?
Yes No

Seek technical support End

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 28

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2.6.3 Troubleshooting Procedure

Procedure
Step 1 Check that unicast routes are available.

Run the display ip routing-table command on each PE and P to check whether devices on the
public network are reachable through unicast routes.

Run the display ip routing-table vpn-instance vpn-instance-name command on the PEs to

check whether the devices in each VPN instance bound to the PEs are reachable through unicast
routes.

Run the ping command on CEs to check whether CEs are routable in each VPN instance.

l If unicast routes are unavailable, check the faults of unicast routes. For details, see BGP
Private Network Traffic Is Interrupted.
l If unicast routes are available on both the public network and VPNs, go to Step 2.

Step 2 Check that the TTL value of the multicast data sent by the multicast source is sufficient to reach
the destination.

Confirm the TTL value of the multicast data with customers or the supplier of the multicast
source device.

l If the TTL value is smaller than the number of hops of the path from the multicast source
to the receiver, you are recommended to increase the TTL value of the multicast data sent
from the multicast source.
l If the TTL value is equal to or greater than the number of hops of the path from the multicast
source to the receiver, go to Step 3.

Step 3 Check that multicast is enabled on both the public network and VPNs.

Run the display current-configuration command on each device to check current

configurations. Focus on checking configurations on each PE.

Multicast VPN requires PEs to support multicast multi-instance. The following are configuration
requirements on PEs:

The multicast routing-enable command is run in the system view to enable multicast on the
public network.

The multicast routing-enable command is run in the view of each VPN instance bound to PEs
to enable multicast in each VPN instance.

l If multicast routing-enable is not displayed in the configurations of an instance bound to

a PE, multicast is not enabled in this instance. Then run the multicast routing-enable
command in the VPN instance view.
l If multicast routing-enable is displayed in the configurations of the public network
instance and all the VPN instances, go to Step 4.

Step 4 Check that configurations of the share-groups configured for the same VPN instance to which
PEs are bound are consistent.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 29

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Run the display multicast-domain vpn-instance vpn-instance-name share-group command

on PEs to check that configurations of the share-groups configured for a specified VPN instance
are consistent.
l If share-groups are not configured or configurations of share-groups are different, run the
multicast-domain share-group group-address binding mtunnel number command in
this VPN instance view to reconfigure a share-group and bind the share-group to a specified
MTI.
l If the configurations of the share-groups configured for the specified VPN instance are
consistent, go to Step 5.
Step 5 Check that configurations of the MTIs on PEs are correct.
Run the display current-configuration command on each PE to check whether the MTI address
is correct and consistent with the address of the local interface setting up an IBGP peer
relationship.
l If no MTI is configured or the address of the MTI is inconsistent with that of the local
interface setting up an IBGP peer relationship, the multicast packet can reach the VPN
instance on the PE through the MTI, but cannot pass the RPF check. Then run the ip
address ip-address { mask | mask-length } command in the MTI view to change the IP
address of the MTI.
Check whether the MTI is running the same PIM protocol with the VPN. If not, change the
PIM protocol configured on the MTI.
l If MTIs on PEs are correctly configured, go to Step 6.
Step 6 Check that PIM neighbor relationships are established between devices.
Run the display pim [ vpn-instance vpn-instance-name ] neighbor command on devices to
check whether they have set up PIM neighbor relationships correctly. Focus on checking whether
MTIs on PEs are running the same PIM protocol and whether PIM neighbor relationships are
correctly established between them. If the command output shows related neighbor addresses,
neighbor relationships are correctly established.
l If no PIM neighbor relationship is established, do as follows:
1. Check whether interfaces are in the Up state.
Run the display interface interface-type interface-number command to check
whether interfaces are in the Up state. If all the interfaces (including MTIs) on the
devices on the public network and VPNs are Up, enable PIM-SM or PIM-DM in the
interface view.
2. Check whether the devices on the public network or the devices on a VPN are running
the same PIM protocol.
Run the display current-configuration command on devices in VPNs to check
whether devices in the same VPN are running the same PIM protocol, and run the
display current-configuration command on PEs to check whether the interfaces
and MTIs bound to the same VPN instance are running the same PIM protocol
with devices in this VPN instance. Focus on checking whether MTIs bound to the
same VPN instance on PEs are running the same PIM protocol with devices in this
VPN instance. If not, enter the associated interface view and reconfigure a PIM
protocol.
Run the display current-configuration command on devices on the public
network to check whether the devices on the public network are running the same

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 30

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

PIM protocol, and run the display current-configuration command on PEs to

check whether interfaces in the public network instance are running the same PIM
protocol with devices on the public network. If not, enter the associated interface
view and reconfigure a PIM protocol.
NOTE

PIM protocols run on the public network and VPNs can be inconsistent.
3. Check that the interfaces that set up BGP peer relationships on the public network can
normally forward Hello messages.
Run the display pim vpn-instance vpn-instance-name control-message counters
interface interface-type interface-number message-type hello command to check
whether interfaces that set up BGP peer relationships on the public network can
normally forward Hello messages. If the number of packets sent and received in more
than one Hello interval continues to increase, packet forwarding is normal. If packet
forwarding is abnormal, contact Huawei technical support personnel.
l If PIM neighbor relationships are correctly established between devices, go to Step 7.

Step 7 Check that the PIM-SM BSR and RP are correctly configured.
l If PIM-SM is enabled in VPNs, the BSR and RP must also be configured in each VPN.
Run the display pim vpn-instance vpn-instance-name bsr-info command on PEs to
check BSR information of each VPN instance. If the elected BSR addresses in the same
VPN instance bound to the PEs are consistent, BSR configurations are correct.
Run the display pim vpn-instance vpn-instance-name rp-info group-address
command on PEs to check whether configurations of the RPs serving the same group
in the same VPN instance bound to the PE are consistent. If the BSR RP addresses are
consistent, RP configurations are correct.
Run the display pim bsr-info command on devices in VPNs to check BSR information.
If elected BSR addresses used by the devices are consistent in each VPN, BSR
configurations are correct.
Run the display pim rp-info command on devices in VPNs to check RP information.
If the BSR RP addresses on the devices are consistent in each VPN, RP configurations
are correct.
l If PIM-SM is enabled on the public network, the BSR and RP must also be configured on
the public network.
Run the display pim bsr-info command on PEs and the P to check BSR information
of the public network. If the elected BSR addresss in the command output on the PEs
and P are consistent, BSR configurations are correct.
Run the display pim bsr-info command on PEs and the P to check RP information of
the public network. If the BSR RP addresses in the command output on the PEs and P
are consistent, RP configurations are correct.
l If PIM-SM BSR and RP configurations are correct, go to Step 8.

Step 8 Check that group addresses are within the SSM group address range.
NOTE

If PIM-SSM is used, this step is mandatory. If PIM-SM is used, skip this step.
l If PIM-SSM is enabled in VPNs, a uniform SSM group address must be configured for all
the devices in each VPN.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 31

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Run the display current-configuration command on PEs to check whether the devices
in same VPN instance bound to the PEs are configured and are with the same SSM
group address range. If the configurations of an instance do not contain the SSM policy
configuration or the address ranges defined in the ACL of the SSM policies are
consistent, it indicates configurations are consistent. If the configurations are
inconsistent, enter the PIM view of the VPN instance and run the ssm-policy basic-acl-
number command to reconfigure an SSM group address range.
Run the display current-configuration command on devices in VPNs to check whether
the devices in each VPN are configured and are with the same SSM group address range.
If the configurations of an instance do not contain the SSM policy configuration or the
address ranges defined in the ACL of the SSM policies are consistent on the devices in
each VPN, it indicates configurations are consistent. If the configurations are
inconsistent, enter the PIM view of the VPN instance and run the ssm-policy basic-acl-
number command to reconfigure an SSM group address range.
l If PIM-SSM is enabled on the public network, a uniform SSM group address must be
configured for all the devices on the public network.
Run the display current-configuration command on PEs and the P to check whether the
PEs and P are configured and are with the same SSM group address range. If the
configurations are inconsistent, enter the PIM view and run the ssm-policy basic-acl-
number command to reconfigure an SSM group address range.
l If the group addresses are within the SSM group address range, go to Step 9.

Step 9 Check whether a multicast boundary is configured.

Run the display multicast [ vpn-instance vpn-instance-name ] forwarding-table command on

the intermediate nodes in sequence from the receiver to the source and check the value of the
Forwarded changes within several minutes. If the value of Forwarded does not change on a
device, it indicates packet forwarding fails on this device. Then run the display multicast [ vpn-
instance vpn-instance-name ] boundary [ group-address ] command on the faulty device. Two
situations are involved:
l For the public network, if the RPT has been switched to the SPT, group-address is an address
in the switch-group address pool; if the RPT has not been switched to the SPT, group-
address is the share-group address.
l For VPNs, group-address is a private multicast group address.

l If the interface configured with a multicast boundary is an RPF interface to the upstream
device, run the undo multicast boundary { group-address { mask | mask-length } | all }
command to delete or change the multicast boundary configurations.
l If no multicast boundary is configured on the interface, go to Step 10.

Step 10 Check that the interfaces that directly connect CEs to hosts have IGMP group information.

Run the display igmp group interface interface-type interface-number command to check
whether the interfaces that directly connect CEs to hosts have IGMP group information.

l If no IGMP group information exists, see the troubleshooting procedures in The Multicast
Device Cannot Generate IGMP Entries or MLD Entries.
l If the fault persists after the preceding troubleshooting procedures are complete, contact
Huawei technical support personnel.

----End

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 32

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2.6.4 Relevant Alarms and Logs

Relevant Alarms
None.

Relevant Logs
None.

2.7 The Multicast Device Cannot Generate IGMP Entries or

MLD Entries

2.7.1 Common Causes

This fault is commonly caused by one of the following causes:

l Multicast is not enabled on the device.

l IGMP or MLD is not enabled on the interface or the configured IGMP or MLD version is
incorrect.
l The interface receives an EXCLUDE message in which the group address is within the
SSM group address range.
l A multicast boundary or a group policy is configured on the interface.
l A limit on the maximum number of IGMP or MLD group memberships is configured on
the interface.

2.7.2 Troubleshooting Flowchart

After configurations are complete on a multicast network, the multicast device cannot generate
IGMP or MLD entries.

Figure 2-7 shows the troubleshooting flowchart.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 33

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-7 Troubleshooting flowchart: the multicast device cannot generate IGMP entries
Multicast device cannot
generate IGMP entries or MLD
entries

Is fault Yes
No
Is multicast enabled? Enable IGMP or MLD rectified?
No
Yes
Yes
No Rectify the Is fault
Is Interface in Up state? interface fault rectified?
No
Yes
Is IGMP or MLD No Enable IGMP or MLD Is fault Yes
enabled on interface? enabled on interface rectified?
No
Yes
Multicast Yes Ensure that the group Yes
Is fault
Group in SSM group address address is in the SSM
rectified?
range? group address range
No
No
Ensure that the group
Is range of groups Yes
is in the range of the Is fault Yes
that hosts can join limited on groups that the rectified?
interface? interface serves No
No

Maximum Increase maximum

number of IGMP or MLD Yes number of IGMP or MLD Yes
Is fault
group memberships limited group memberships on rectified?
on interface? the interface or remove
limit No
No
Increase maximum
Maximum Yes Is fault Yes
number of IGMP or MLD
of group memberships limited
Yes rectified?
group memberships in
in current instance?
interface or remove limit
No
No
Increase maximum of
Maximum Yes Yes
global IGMP or MLD Is fault
of IGMP or MLD group
group memberships rectified?
memberships is limited
on interface or remove
globally?
limit No
No

Are The
Yes Yes
Number of Entries And Re-plan network Is fault
That of interfaces below the deployment rectified?
upper limit?
No
No

Seek technical support End

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 34

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2.7.3 Troubleshooting Procedure

Context
NOTE

Saving the results of each troubleshooting step is recommended. If troubleshooting fails to correct the fault,
a record of the actions taken will exist to provide to Huawei technical support personnel.

Procedure
Step 1 Check that multicast is enabled on the device.

Run the display current-configuration command on the device that is directly connected to
hosts to check the current configurations of the device.

l If the command output does not contain multicast routing-enable, run the multicast
routing-enable command in the system view to enable multicast on the device first and
then complete other IGMP or MLD configurations. For details, see the HUAWEI
NetEngine80E/40E Configuration Guide - IP Multicast.
l If multicast has been enabled on the device, go to Step 2.

Step 2 Check that the interface status is Up.

Run the display interface interface-type interface-number command on the device to check the
configuration of the interface directly connected to the network segment of the hosts.

l If the command output shows interface-type interface-number current state: DOWN,

the interface is physically Down. Check the networking and ensure that the interface is
properly connected.
l If the command output shows Line protocol current state : DOWN, the protocol status
of the interface is Down. Perform the following operations:
Check whether the interface is in the shutdown state.
Run the display current-configuration interface interface-type interface-number
command to check the current configurations of the interface. If the command output
shows shutdown, run the undo shutdown command in the interface view.
Check whether an IP address is configured for the interface.
Run the display current-configuration interface interface-type interface-number
command to check the IP address of the interface. If an IP address is not configured for
the interface or the configured IP address is on a different network segment from the
hosts, run the ip address ip-address { mask | mask-length } command to reconfigure
an IP address for the interface and ensure that the IP address is on the same network
segment with those of the hosts.
l If the interface status is Up, go to Step 3.

Step 3 Check that IGMP or MLD is enabled on the interface.

Run the display current-configuration interface interface-type interface-number command to

check the current configurations of the interface that is directly connected to the hosts.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 35

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

l If the command output does not contain igmp enable nor mld enable, neither IGMP nor
mld enable is enabled on the interface. Run the igmp enable command or the mld
enable command in the interface view to enable IGMP or MLD.
l If IGMP or MLD has been enabled on the interface, go to Step 4.

Step 4 Check whether the multicast group G of the EXCLUDE message is in the SSM group address
range.

Run the display current-configuration configuration pim command on the device that is
directly connected to hosts to check the current configurations in the PIM view. If the command
output shows ssm-policy basic-acl-number, the SSM group address range is defined on the
device. Then, run the display acl acl-number command to check the ACL configurations.

l If the command output shows that the multicast group G is in the address range permitted
by the ACL, G belongs to the SSM group address range. Ensure that IGMPv3 or MLDv2
is running between the host and the interface on the device.
If the version of IGMP or MLD running on the host cannot be upgraded, enable SSM
mapping on the device interface and create static SSM mapping rules for G.
l If the command output shows that the multicast group G is in the address range denied by
the ACL, G belongs to the ASM group address range. Adjust the group address range
specified in the ACL so that G is in the address range permitted by the ACL.
l If the multicast group G is not in the SSM address range and the configured IGMP or
MLD version is correct, go to Step 5.

Step 5 Check whether the range of groups that the hosts can join is limited on the interface.

Run the display igmp interface interface-type interface-number command (in the IPv4
scenario) or the display mld interface interface-type interface-number command (in the IPv6
scenario) to check the current configurations of the interface that is directly connected to the
hosts.

l If the group-policy field in the command output is not none, the range of groups the hosts
can join is limited on the interface. IGMP or MLD then filters Report or Join messages of
the hosts according to the ACL. Check the range of the groups permitted by the ACL. If
the multicast group G is not in this range, modify the ACL or delete the ACL configuration
to ensure that IGMP or MLD can serve members of G.
l If the range of groups that the hosts can join is not limited on the interface, go to Step 6.

Step 6 Check whether the maximum number of IGMP or MLD group memberships is limited on the
interface.

Run the display igmp interface interface-type interface-number command (in the IPv4
scenario) or the display mld interface interface-type interface-number command (in the IPv6
scenario) to check the current configurations of the interface that is directly connected to the
hosts.

l If the IGMP limit or the MLD limit field in the command output does not display -, the
maximum number of IGMP or MLD group memberships is limited on the interface. Run
the igmp limit number command (in the IPv4 scenario) or the mld limit number command
(in the IPv6 scenario) to increase the IGMP limit or MLD limit, or run the undo igmp
limit command (in the IPv4 scenario) or the undo mld limit command (in the IPv6
scenario) to delete the configured IGMP limit or MLD limit.
l If the IGMP limit or the MLD limit field in the command output is -, go to Step 7.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 36

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Step 7 Check whether the maximum number of IGMP or MLD group memberships is limited in the
current instance.

Run the display current-configuration configuration igmp command (in the IPv4 scenario)
or the display current-configuration configuration mld command (in the IPv6 scenario) to
check the configurations of the IGMP limit or MLD limit in the current instance.

l If the command output shows the configurations of the IGMP limit or MLD limit for the
instance, the maximum number of IGMP or MLD group memberships is limited in this
instance. Then, run the limit number command in the IGMP view of the instance (in the
IPv4 scenario) or the limit number command in the MLD view of the instance (in the IPv6
scenario) to increase the IGMP limit or MLD limit, or run the undo limit command in the
IGMP view of the instance (in the IPv4 scenario) or the undo limit command in the MLD
view of the instance (in the IPv6 scenario) to delete the configured IGMP limit or MLD
limit.
l If the command output does not contain the configurations of the IGMP limit or MLD
limit for the instance, go to Step 8.

Step 8 Check whether the maximum number of IGMP or MLD group memberships is limited globally.

Run the display current-configuration | include igmp global limit command (in the IPv4
scenario) or the display current-configuration | include mld global limit command (in the
IPv6 scenario) to check the global configurations of the IGMP limit or MLD limit.

l If there is command output, the maximum number of IGMP or MLD group memberships
is limited globally. Then, run the igmp global limit number command in the system view
(in the IPv4 scenario) or the mld global limit number command in the system view (in the
IPv6 scenario) to increase the IGMP limit or MLD limit, or run the undo igmp global
limit command in the system view (in the IPv4 scenario) or the undo mld global limit
command in the system view (in the IPv6 scenario) to delete the set IGMP limit or MLD
limit.
l If there is no command output, go to Step 9.

Step 9 Check that the number of entries and number of interfaces are below the upper limit defined in
the product license.
l If the number of entries and number of interfaces exceed the upper limit defined in the
product license, re-plan network deployment.
l If the fault persists after the preceding troubleshooting procedures are complete, go to Step
10.

Step 10 Collect the following information and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure
l Configuration files, log files, and alarm files of the device

----End

2.7.4 Relevant Alarms and Logs

Relevant Alarms
None.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 37

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Relevant Logs
None.

2.8 Related Troubleshooting Cases

2.8.1 The IPTV Screen Freezes Up Due to the Low Performance of

a Downstream Device

Fault Symptom
As shown in Figure 2-8, the upstream interface of Router A is connected to the multicast source
and the downstream interface of Router A is connected to an SDH device. Router A is connected
to devices in four areas through the SDH device.

Figure 2-8 Typical networking diagram of IPTV services

Server
Network

Router A

SDH

Router B Router C Router D Router E

When IPTV services are deployed in any two of the four areas, the IPTV services are normal.
After IPTV services are deployed in a third area, it is found that the IPTV screen freezes up,
regardless of whatever program is selected.

Fault Analysis
1. Run the display interface interface-type interface-number command on Router A to view
traffic statistics on the interface connecting Router A to the SDH device, you can find that
the SDH device sends pause frames.
<HUAWEI> display interface GigabitEthernet1/0/1
GigabitEthernet1/0/1 current state : UP

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 38

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Description:TO-4-ALL
Switch Port,The Maximum Transmit Unit is 1500
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is
0018-8287-103b
The Vendor PN is FTLF8519P2BNL-HW
Port BW: 1G, Transceiver max BW: 1G, Transceiver Mode: MultiMode
WaveLength: 850nm, Transmission Distance: 500m
Rx Power: -5.10dBm, Tx Power: -4.70dBm
Loopback:none, full-duplex mode, negotiation: disable, Pause
Flowcontrol:Receive Enable and Send Enable
Last physical up time : 2009-02-20 14:57:16
Last physical down time : 2009-02-20 14:34:13
Statistics last cleared:never
Last 300 seconds input rate: 37984 bits/sec, 15 packets/sec
Last 300 seconds output rate: 138591960 bits/sec, 12692 packets/sec
Input: 32263137647 bytes, 382749578 packets
Output: 5370966792005 bytes, 3892496947 packets
Input:
Unicast: 376648557 packets, Multicast: 6100346 packets
Broadcast: 675 packets, JumboOctets: 659362 packets
CRC: 0 packets, Symbol: 0 packets
Overrun: 0 packets
InRangeLength: 0 packets
LongPacket: 0 packets, Jabber: 0 packets, Alignment: 0 packets
Fragment: 0 packets, Undersized Frame: 0 packets
RxPause: 5307820 packets
Output:
Unicast: 692424410 packets, Multicast: 3200072319 packets
Broadcast: 218 packets, JumboOctets: 116058 packets
Lost: 0 packets, Overflow: 0 packets, Underrun: 0 packets
TxPause: 0 packets
Unknown Vlan: 0 packets

Field Description

Enable and Send Enable Indicates that the function of sending pause
frames and the function of receiving pause
frames are enabled.

RxPause: 5307820 packets Indicates the number of pause frames

received from the downstream device.
If the interface receives a large number of
pause frames, it indicates that the
performance of the downstream device is
low.

TxPause: 0 packets Indicates the number of pause frames sent

by the interface of the downstream device
to the upstream device.
If the processing capability of the interface
of the downstream device is low, the
interface sends pause frames to the
upstream device.

If the interface of the upstream interface receives pause frames, it indicates that the
receiving capability of the interface of the downstream interface exceeds the bandwidth
and that the bandwidth of the downstream device needs to be adjusted.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 39

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

NOTE

After flow control is enabled on an interface, when the volume of received traffic on the interface
reaches the threshold, the interface sends a pause frame to the peer interface, instructing the peer
interface to send data at a slower rate. If the peer interface also supports flow control, it sends data
at a slower rate after receiving the pause frame so that the local interface can process received frames
properly.

Procedure
Step 1 Modify the working mode of the SDH device to restore IPTV services.

----End

Summary
The main cause of the fault is that packet loss occurs or there is a long delay during IPTV packet
forwarding. When locating the fault, first check whether the bandwidth required by IPTV traffic
exceeds the bandwidth configured on the associated interface by checking the statistics about
pause frames on the interface.

2.8.2 The IPTV Screen Messes Up Due to Uneven Eth-Trunk Load

Balancing

Fault Symptom
As shown in Figure 2-9, the upstream interface of Router A is connected to the multicast source,
and the downstream interface of Router A is connected to a transmission device through an Eth-
Trunk. The Eth-Trunk contains four physical links, and the bandwidth of each physical link is
limited to 900 Mbit/s on the transmission device.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 40

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-9 Typical networking diagram of IPTV services

IPTV
Server
Network

Router A

Eth-Trunk 1

SDH

Eth-Trunk 1

Router B

Network

User A
User B

When a user attached to Router B demands programs, the IPTV screen messes up.

Fault Analysis
1. Run the display interface interface-type interface-number command on Router A to check
the traffic statistics on the Eth-Trunk. You can find that the Eth-Trunk contains four
physical interfaces and the traffic volume on the Eth-Trunk exceeds 1 Gbit/s.
It is therefore suspected that the system uses one physical link to transmit all multicast
traffic, causing multicast packet loss.
<HUAWEI> display interface eth-trunk 1
Eth-Trunk1 current state : UP
Line protocol current state : UP
Last line protocol up time : 2009-01-07 14:36:55
Description:to qijiang
Route Port,Hash arithmetic : According to flow,The Maximum Transmit Unit is
4470
Internet Address is 192.168.101.26/30
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is
0018-823a-0f7c
Physical is ETH_TRUNK
Statistics last cleared: never
Last 300 seconds input rate 5597080 bits/sec, 1280 packets/sec
Last 300 seconds output rate 1008843296 bits/sec, 92605 packets/sec
Input: 1388399703 packets,144191346946 bytes,
46878092 unicast,919 broadcast,1341520692 multicast
0 errors,0 drops
Output:292945617342 packets,398897930190227 bytes,

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 41

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

316935181 unicast,1994 broadcast,292628680167 multicast

160 errors,160 drops
-----------------------------------------------------------------------------
PortName Status Weight
-----------------------------------------------------------------------------
GigabitEthernet1/0/1 UP 1
GigabitEthernet1/0/2 UP 1
GigabitEthernet1/0/3 UP 1
GigabitEthernet1/0/4 UP 1
-----------------------------------------------------------------------------
The Number of Ports in Trunk : 4
The Number of UP Ports in Trunk : 4

2. Check traffic statistics on each physical interface of Router A. You can find that GE 1/0/3
receives pause frames from the downstream device. It is therefore suspected that the system
sends all multicast traffic to GE 1/0/3, causing the bandwidth required by outgoing traffic
exceeds the bandwidth configured on the downstream device.
<HUAWEI> display interface gigabitethernet 1/0/3
GigabitEthernet1/0/3 current state : UP
Line protocol current state : UP
Description:to qijiang
Route Port,The Maximum Transmit Unit is 1500
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is
0018-823a-9d87
The Vendor PN is FTRJ1319P1BTL
Port BW: 1G, Transceiver max BW: 1G, Transceiver Mode: SingleMode
WaveLength: 1310nm, Transmission Distance: 10km
Rx Power: -5.67dBm, Tx Power: -5.52dBm
The set port type is: fiber-1000
Loopback:none, full-duplex mode, negotiation: disable, Pause
Flowcontrol:Receive Enable and Send Enable
Last physical up time : -
Last physical down time : 2008-11-28 05:10:10
Statistics last cleared:2008-11-28 06:00:40
Last 300 seconds input rate: 403432 bits/sec, 785 packets/sec
Last 300 seconds output rate: 890720544 bits/sec, 81749 packets/sec
Input: 62430714273 bytes, 964579319 packets
Output: 175720989207928 bytes, 129026940264 packets
Input:
Unicast: 2980464 packets, Multicast: 961598854 packets
Broadcast: 1 packets, JumboOctets: 1081 packets
CRC: 0 packets, Symbol: 0 packets
Overrun: 0 packets
InRangeLength: 0 packets
LongPacket: 0 packets, Jabber: 0 packets, Alignment: 0 packets
Fragment: 0 packets, Undersized Frame: 0 packets
RxPause: 953718281 packets
Output:
Unicast: 42166250 packets, Multicast: 128984774013 packets
Broadcast: 1 packets, JumboOctets: 35667 packets
Lost: 0 packets, Overflow: 160 packets, Underrun: 0 packets
TxPause: 0 packets
Unknown Vlan: 0 packets

3. Run the display multicast routing-table command on Router A to check the multicast
routing table. You can find that there are only two multicast entries with Eth-Trunk 1 as
the outbound interface.
<HUAWEI> display multicast routing-table
Multicast routing table of VPN-Instance: public net
Total 3 entries
00001. (150.158.231.1, 239.0.0.1)
Uptime: 2w:0d
Upstream Interface: GigabitEthernet3/0/2
List of 3 downstream interfaces
1: Eth-Trunk3
2: Eth-Trunk1

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 42

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

3: Eth-Trunk2
00002. (150.158.233.3, 239.0.0.1)
Uptime: 2w:0d
Upstream Interface: GigabitEthernet3/0/20
List of 3 downstream interfaces
1: Eth-Trunk3
2: Eth-Trunk1
3: Eth-Trunk2
00003. (172.16.15.2, 239.0.0.1)
Uptime: 06:44:03
Upstream Interface: Eth-Trunk3
List of 2 downstream interfaces
1: Eth-Trunk3
2: Eth-Trunk2

Because the packets are from the same multicast group, the system selects the same physical
link for all multicast traffic based on the hash algorithm. As a result, the function of the Eth-
Trunk is not brought into play.

NOTE

Generally, each channel is one multicast group. At this site, however, all channels are added to a multicast
group, and are distinguished based on the devices connected to Router A. As a result, the function of the
Eth-Trunk is not brought into play.

Procedure
Step 1 Increase the bandwidth of the transmission device to rectify the fault. This is because about 900
Mbit/s traffic of the total 1 Gbit/s traffic delivered by the multicast source is transmitted through
GE 1/0/3.

----End

Summary
Because the multicast packets are from the same multicast group, all multicast traffic is
transmitted through the same physical link of the Eth-Trunk. As a result, the function of the Eth-
Trunk is not brought into play and the IPTV screen messes up, although the total bandwidth of
the Eth-Trunk is more than that required by the multicast traffic.

2.8.3 IPTV Services Are Interrupted Because an Invalid Dynamic

RP Is Elected

Fault Symptom
On the network, IPTV services are deployed; PIM-SM is run; static RPs are configured; the
IPTV services of users are normal.

Due to network adjustment, all the IPTV services of users are interrupted, and the users cannot
watch programs of any channel.

Fault Analysis
1. Run the display pim routing-table command to check the (S, G) and (*, G) entries on the
device. You can find that the device cannot generate any entry.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 43

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2. Run the display pim rp-info command to check the RPs serving multicast groups. You
can find that there are two RPs. One RP is a static RP with the IP address being a public
network address, and the other RP is a dynamic RP with the IP address being a private
network address.
By default, the dynamic RP takes precedence over the static RP. It is confirmed that the
network uses static RPs based on network planning. The devices on the network, however,
prefer the invalid dynamic RP, causing the IPTV services to be interrupted.
3. Run the debugging pim rp command. You can find that the IP address of the device that
advertises the dynamic RP is 113.132.128.13.
<HUAWEI> debugging pim rp
*4.567973591 XA-FZC-FZCJ-K-MA52G-1.MAN PIM/7/RP:(public net): PIM ver 2 C-RP
receiving 113.132.128.13 -> 222.90.205.94 on GigabitEthernet1/0/0 (S01534)
*4.567973591 XA-FZC-FZCJ-K-MA52G-1.MAN PIM/7/RP:(public net): C-RP
192.168.1.2, pref count 1, Priority: 192, holdtime 150 (S01553)
*4.567973591 XA-FZC-FZCJ-K-MA52G-1.MAN PIM/7/RP:(public net): 224.0.0.0/4
(S01583)
*4.567973592 XA-FZC-FZCJ-K-MA52G-1.MAN PIM/7/RP:(public net): Admin Scope
Zone: 0 (S01584)
*4.567973592 XA-FZC-FZCJ-K-MA52G-1.MAN PIM/7/RP:(public net): Received C-RP-
Adv from 113.132.128.13, npfx: 1, priority: 192, holdtime: 150, RP address:
192.168.1.2 (S04682)

You can use one of the following solutions to restore the IPTV services:

l Delete the dynamic RP configuration.

The prerequisite of this solution is that the configurations of the network devices are correct.
This solution can temporarily prevent the fault, and cannot thoroughly rectify the fault.
l Increase the priorities of the static RRs.
This solution needs to be carried out on all devices on the entire network, and the workload
is extremely heavy. Therefore, the solution is not feasible.
l Configure an ACL on the BSR to filter out packets from the invalid dynamic RP.

On the current network, the solution of configuring an ACL on the BSR is adopted, because site
engineers do not have the right to modify the configuration of other devices.

Procedure
Step 1 Run the acl acl-number to enter the ACL view.
NOTE

You need to set the rules for the advanced ACL. The value of acl-number ranges from 3000 to 3999.

Step 2 Run the rule rule-id permit ip source ip-address command to configure ACL rules to permit
packets from a valid RP to pass through. ip-address specifies the address of the valid RP.

Step 3 Run the pim command to enter the PIM view.

Step 4 Run the crp-policy advanced-acl-number command to limit the range of valid RP addresses.

----End

Summary
The priorities of the following types of RPs are as follows:

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 44

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

l Static RP configured with the static-rp rp-address [ basic-acl-number | acl-name acl-

name ] preferredcommand: has the highest priority.
l Dynamic RP: has the second highest priority.
l Common static RP configured with the static-rp rp-address [ basic-acl-number | acl-
name acl-name ] command: has the lowest priority.

2.8.4 IPTV Channels Are Lost Because PIM Is Not Configured

Fault Symptom
On the network, there are 108 channels, Router A functions as the RP, and Router C functions
as the receiver's DR. Router B and Router C are connected through two links among which load
balancing is carried out. Router A and Router B are connected through three links among which
load balancing is carried out.

Figure 2-10 Typical networking diagram of IPTV services

Router A
POS 2/0/0 GE 1/0/0
GE 1/0/1
GE 1/0/1
POS 2/0/0 GE 1/0/0
Router B

Router C

Network

User A
User B

Ten channels are lost on Router C, and users cannot watch the programs of these channels. Users
can normally watch the programs of the other 98 channels.

Fault Analysis
1. Run the display pim routing-table command on Router A, Router B, and Router C in
sequence to check the PIM routing table. You can find that there are 98 (S, G) entries on
each device, and 10 (S, G) entries are lost, which is consistent with the fault symptom.
There are 108 (*, G) entries on only Router C, and Router A and Router B do not have any
(*, G) entry.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 45

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Because the two devices do not generate any (*, G) entry, the two devices cannot generate
any (S, G) entry, and multicast channels are lost. It is primarily concluded that the fault
occurs on Router B.
2. Run the debugging pim join-prune command on Router B to view the debugging of Join
messages. You can find that all Join messages are discarded, because the RP address is
invalid or the RP is unreachable.
<HUAWEI> debugging pim join-prune
*6.365990474 PE_OUJDA_01_CEX PIM/7/JP:(public net): PIM-SM: Invalid RP-address
or RP not found, Ignoring (*,239.255.0.151) join received on
GigabitEthernet4/0/0.3 (S12300)
*6.365990475 PE_OUJDA_01_CEX PIM/7/JP:(public net): PIM-SM: Invalid RP-address
or RP not found, Ignoring (*,239.255.0.150) join received on
GigabitEthernet4/0/0.3 (S12300)

3. On Router B, check the reachability of the RP. Run the pim command to enter the PIM
view. Then, run the display this command in the PIM view to identify the IP address of
the RP.
<HUAWEI> system-view
[HUAWEI] pim
[HUAWEI-pim] display this
#
pim
static-rp 196.217.250.111
#
return

The RP is statically configured, and the IP address of the RP is 196.217.250.111. There are
three links among which load balancing is carried between Router B and the RP. The
outbound interfaces of the links are GE 1/0/1, GE 1/0/2, POS 2/0/0 respectively. Check the
RPF interface, and you can find that the RPF interface is POS 2/0/0. POS 2/0/0, however,
is not configured with PIM-SM, which causes the RP to be unreachable for PIM-SM. As
a result, all Join messages are discarded, and are not sent to Router A.
NOTE

In multicast, the outbound interface with the largest IP address functions as the RPF interface. In the
troubleshooting case, the IP address of POS 2/0/0 is largest, and therefore POS 2/0/0 is selected as
the RPF interface.
<HUAWEI> display multicast rpf-info 196.217.250.111
VPN-Instance: public net
RPF information about source: 196.217.250.111
RPF interface: POS 2/0/0
Referenced route/mask: 196.217.250.111/32
Referenced route type: unicast
Route selection rule: preference-preferred
Load splitting rule: disable

NOTE

Why are the programs of the other 98 channels normally watched?

Multicast flows are forwarded on the basis of (S, G) entries. As long as (S, G) entries are generated,
multicast flows can be forwarded. Check the (S, G) entries on Router B, and you can find that SPT
switchover occurs. After the SPT switchover, (S, G) entries are generated based on (S, G) Join
messages to be sent to the source's DR.
In the troubleshooting case, PIM-SM is enabled and a multicast static route is configured on GE 1/0/0
of Router B. The programs of the channels for which (S, G) entries are generated can be normally
watched.

You can use either of the following methods to rectify the fault:

l Enable PIM-SM on POS 2/0/0.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 46

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

l Configure a multicast static route on GE 1/0/0 and set GE 1/0/0 as the outbound interface
of the multicast static route.

In this case, the second method is used to rectify the fault.

Procedure
Step 1 Run the interface interface-type interface-number command on Router B to enter the interface
view.

Step 2 Run the ip rpf-route-static source-address protocol process-id rpf- br command to configure
the interface as the RPF interface.

----End

Summary
Multicast forwarding depends on unicast routes. PIM needs to be configured on the nodes along
the path from the multicast source to a receiver. In the case of load balancing, PIM or a multicast
static route needs to be configured on the nodes along each path.

2.8.5 The IPTV Has Sound but No Picture Due to Incorrect ACL
Configurations

Fault Symptom
Router A and Router B function as PEs to provide IPTV services for users. To prevent users
attached to the DSLAM to access the routers, an ACL is configured on each of the routers to
permit only valid services.

Figure 2-11 Diagram of the networking where the IPTV has sound but no picture due to incorrect
ACL configurations

Router A Router B

DSLAM

STB
PC

TV

After the network is configured, it is found that the IPTVs at the user side have sound but no
picture.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 47

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Fault Analysis
1. Access the DSLAM from a PC, and then demand IPTV programs through the video on-
demand software. Then, the problem is reproduced.
2. Check the traffic on the interface of the NIC of the PC. You can find that the volume of the
traffic received by the PC is up to 1.4 Mbit/s. Normally, the traffic of an IPTV program is
0.7 Mbit/s. It is therefore suspected that no receiver's DR is elected from Router A and
Router B and both devices send multicast data flows to the PC.
3. Run the display acl acl-number command to check the ACL configuration. You can find
that PIM Hello packets are filtered out because the ACL is configured. Consequently, the
receiver's DR cannot be correctly elected, and multicast data flows cannot be correctly
forwarded.
<HUAWEI> display acl 3001
Advanced ACL 3001, 10 rules
permits communication with DHCP server, IPTV portal, Multicast source
equipment
at Headend
Acl's step is 5
rule 5 permit udp source 0.0.0.0 0 destination-port range bootps bootpc
rule 10 permit ip destination 10.80.8.0 0.0.0.255
rule 20 permit ip destination 10.80.9.0 0.0.0.255
rule 30 permit ip destination 10.227.0.0 0.0.255.255
rule 40 permit ip destination 239.150.150.0 0.0.0.255
rule 50 permit ip destination 239.150.151.0 0.0.0.255
rule 60 permit ip destination 239.150.152.0 0.0.0.255
rule 70 permit ip destination 239.150.153.0 0.0.0.255
rule 80 permit ip destination 239.150.154.0 0.0.0.255
rule 100 deny ip

Procedure
Step 1 Run the acl acl-number command on Router A and Router B respectively to enter the ACL
view.

Step 2 Run the rule 90 permit ip destination 224.0.0.13 0.0.0.0 command to permit PIM Hello packets.
NOTE

The destination address of the PIM Hello packets is 224.0.0.13; the source address is the IP address of the
associated interface; the TTL value is 1.

----End

Summary
When configuring ACL rules, you must ensure that valid multicast protocol packets are not
filtered out by the ACL rules. Otherwise, multicast data flows cannot be normally forwarded.

2.8.6 Certain Channels Are Unavailable Because the Router at the

Source Side Is Not Enabled with a Multicast Protocol on the IPTV
Network

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 48

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Fault Symptom
On the IPTV MAN as shown in Figure 2-12, PIM-SM is configured on the network; Router C
functions as the static RP; Switch C functions as the receiver's DR.

Figure 2-12 Networking diagram of an IPTV MAN

IPTV
Server

Switch B Switch A

Router D Router C

Router B Router A

Switch C

Network

User C
User A

User B

The receiver's DR initiates the generation of an SPT. After the SPT is set up, it is found that
users cannot watch the programs of certain IPTV channels.

Fault Analysis
1. According to the network topology, there are equal-cost routes. One route passes through
Router A, and the other route passes through Router B. Router C functions as the RP, and
there is only one hop between Router A to Router C. Therefore, there are complete (S, G)
and (*, G) entries on Router A.
When Switch C sends Join messages to trigger the establishment of the SPT, some of the
Join messages may be sent to Router B. In this case, when the first (S, G) Join message
reaches Switch C along the SPT, Switch C sends Prune messages along the RPT to the RP.
2. Run the debugging pim join-prune command on Router B to view debugging information.
It is found that Router B receives Join messages from Switch C, creates (S, G) entries, and
sends them to Router D.
<HUAWEI> debugging pim join-prune
*6.575255524 DeviceB PIM/8/EVENT:Public:PIM-SM: Upstream (221.1.1.192,
224.1.1.58) FSM transited from NotJoined to Joined, JoinDesired == True.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 49

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

(S13328)
*6.575255524 DeviceB PIM/8/ROUT:Public:PIM-SM: Deleting iif 221.1.1.38 from
(221.1.1.192, 224.1.1.58). (S011943)
*6.575255524 DeviceB PIM/8/ROUT:Public:PIM-SM: Adding iif 221.1.1.38 to
(221.1.1.192, 224.1.1.58). (S012275)
*6.575255524 DeviceB PIM/8/JP:Public:PIM ver 2 JP sending 221.1.1.38 ->
224.0.0.13 on GigabitEthernet2/0/0 (P011934)
*6.575255524 DeviceB PIM/8/JP:Public:Upstream 221.1.1.37, Groups 1, Holdtime
210 (P011698)
*6.575255524 DeviceB PIM/8/JP:Public:Group: 224.1.1.58/32 --- 1 joins 0 prunes
(P011734)
*6.575255524 DeviceB PIM/8/JP:Public:Join: 221.1.1.192/32 S (P011757)

3. View debugging information on Router D in the same manner. It is found that Router D
receives Join messages and sends them to the upstream device. Router D, however, does
not receive any (S, G) Join messages from the peer device within 210 seconds. Therefore,
the multicast route is pruned.
<HUAWEI> debugging pim join-prune
*6.574204484 DeviceD PIM/8/ROUT:Public:PIM-SM: Adding iif 221.1.1.69 to
(221.1.1.175, 224.1.1.2). (S012275)
*6.574204484 DeviceD PIM/8/JP:Public:PIM ver 2 JP sending 221.1.1.69 ->
224.0.0.13 on GigabitEthernet6/0/0 (P011934)
*6.574204484 DeviceD PIM/8/JP:Public:Upstream 221.1.1.70, Groups 1, Holdtime
210 (P011698)
*6.574204484 DeviceD PIM/8/JP:Public:Group: 224.1.1.2/32 --- 1 joins 0 prunes
(P011734)
*6.574204484 DeviceD PIM/8/JP:Public:Join: 221.1.1.175/32 S (P011757)

*6.574314704 DeviceD PIM/8/JP:Public:Upstream 221.1.1.70, Groups 1, Holdtime
210 (P011698)
*6.574314704 DeviceD PIM/8/JP:Public:Group: 224.1.1.58/32 --- 0 joins 1 prunes
(P011734)
*6.574314704 DeviceD PIM/8/JP:Public:Prune: 221.1.1.192/32 S (P011780)

4. Check the configurations of the upstream device. It is found that PIM is not enabled on the
interfaces of Switch B. As a result, the Join messages from the downstream device cannot
be sent to the multicast source. 210 seconds later, the (S, G) entry on Router D expires and
the entry is therefore deleted.

Procedure
Step 1 After PIM is enabled on the interfaces of Switch B, the services run normally. The fault is
therefore rectified.

----End

Summary
If there are multiple equal-cost routes between the receiver's DR and multicast source, you need
to enable the multicast protocol on each device along each route.

2.8.7 Receivers Attached to a Multicast Interface Experience Video

Lagging

Fault Symptom
On the network shown in Figure 2-13, multicast services are deployed. Router A and Router C
have Receivers attached to them. Receiver attached to Router A experiences video lagging.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 50

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-13 Networking diagram of on-demand multicast programs on an interface

Ethernet

PIM SM

RouterB RouterC

Source

GE1/0/1
RouterA

GE1/0/5
Receiver

Receiver

Fault Analysis
1. Check whether the multicast source works properly.
Receiver attached to Router C can properly receive multicast data. Therefore, it can be
concluded that the multicast source is normal.
2. Check whether Receiver attached to Router A has sent a Report message.
On Router A, run the display igmp routing-table command to check whether information
about IGMP Report messages is displayed. Information about GE1/0/5 on Router A is
displayed:
Total 1 IGMP Group reported
The command output indicates that Router A has received a Report message.
3. Check whether multicast forwarding entries are correctly generated, that is, whether
Router A has a downstream interface to which Receiver attaches.
Run the display multicast forwarding-table command on Router A to check whether
forwarding entries contain downstream interfaces. The multicast forwarding entry list
contains the following information:
1: GE1/0/5
It indicates that Router A has a downstream interface to which Receiver attaches.
4. Check the number of multicast packets sent and received by Router A.
l Run the display this interface command in the view of GE1/0/1 on Router A to check
the number of received multicast packets. The following information is displayed:
Input:
Unicast: 21839, Multicast: 4139477

l Run the display this interface command in the view of GE1/0/5 on Router A to check
the number of sent multicast packets. The following information is displayed:

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 51

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Output:
Unicast: 3, Multicast: 366591

The preceding information shows that GE1/0/1 has received 4,139,477 multicast packets
but GE1/0/5 has sent out only 366,591 multicast packets. This indicates that about 90% of
the packets are lost.
Run the display this command in the view of GE1/0/5 on Router A to check configurations
of GE1/0/5. The following information is displayed:
igmp static-group 224.0.1.0

The preceding information shows that Receiver attached to Router A has joined a multicast
group whose address is in the reserved multicast group address range. (An interface board
reserves the multicast group addresses 224.0.0.0 through 224.0.1.255 for protocol packets.)
Therefore, after receiving multicast packets, interface board considers them as protocol
packets rather than data packets and directly delivers the packets to the main control board
instead of forwarding them to Receiver.
Because the rate at which the interface board delivers protocol packets is limited, the main
control board receives only some packets. The main control board reserves multicast group
addresses 224.0.0.0 through 224.0.0.255 for protocol packets. After receiving multicast
packets, the main control board does not consider the packets as protocol packets and
forwards the packets to the interface board based on the MFIB. Therefore, some traffic fails
to be sent out from GE 1/0/5, in which case Receiver experiences video lagging.

Procedure
l Change the address of the multicast group that Receiver joins. Addresses 224.0.0.0 through
224.0.0.255 are reserved multicast group addresses that cannot be used for multicast data
packet forwarding.

After the preceding operations, multicast data packets can properly reach Receiver. The
fault is rectified.

----End

Summary
Addresses 224.0.0.0 through 224.0.0.255 are reserved multicast group addresses that cannot be
used for multicast data packet forwarding. Therefore, avoid using the addresses within this range
as the group address of multicast data packets.

2.8.8 A Multicast Router Fails to Process BSR Messages Because the

RPF Check Fails

Fault Symptom
On the network shown in Figure 2-14, multicast services are deployed. Router A assumes the
role of both BSR and RP. PIM-SM is configured on every Router. Router Router D has a Receiver
attached to it. After the configurations, Receiver cannot receive multicast traffic.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 52

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-14 Basic multicast networking

RouterA RouterC

Source
PIM-SM

RouterB RoutreD

GE1/0/0

Receiver

Fault Analysis
1. Run the display pim neighbor command on every router to check whether PIM neighbor
relationships are successfully set up.
2. On Router D, run the display igmp routing-table command to check whether information
about IGMP Report messages is displayed. Information about GE 1/0/0 on Router D is
displayed:
Total 1 IGMP Group reported
The preceding command output indicates that Router D has received a Report message.
3. Run the display pim rp-info command on every router to check whether RPs are
successfully created. The command output shows that Router D does not learn about the
RP. A tester is then used to obtain packets. Router C is found to have sent a BSR message
to Router D.
4. On Router D, run the debugging pim event command to locate the fault. The command
output shows that Router D ignores the BSR message sent by Router C because the RPF
check fails.
5. On Router D, run the display ip routing-table command. The command output shows that
the next hop of the route from Router D to the BSR/RP is Router B rather than Router C.

Procedure
Step 1 Run the system-view command to enter the system view.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 53

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Do as follows on Router D:

Step 2 Run the ip route-static ip-address command to configure Router C as the next hop of Router
D.

After the preceding operations, Router D can normally learn the RP and Receiver can receive
multicast data. The fault is cleared.

----End

Summary
The RPF check failure will cause protocol packets unable to be processed. The RPF check affects
the forwarding of both multicast data packets and protocol packets such as BSR packets.
Therefore, in multicast service deployment, ensure that the unicast routing entries are correct to
avoid the RPF check failure.

2.8.9 Users on an IP MAN Fail to Receive IPTV Programs

Fault Symptom
On the IP MAN as shown in Figure 2-15, IPTV channels are deployed. Router A is a non-
Huawei device. Users cannot receive programs from 18 channels through the STB. The
inaccessible channels are 2, 3, 4, 7, 8, 11, 12, 13, 16, 17, 20, 21, 24, 25, 28, 34, 37, and 41. The
first four channels correspond to the multicast groups 239.253.154.4, 239.253.154.5,
239.253.154.6, and 239.253.154.9 respectively.

Figure 2-15 Network diagram of IPTV channels deployment on an IP MAN

GE1/0/0 RouterB
GE2/0/0
Source RouterA

MA5200G

STB

Receiver

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 54

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Fault Analysis
1. Check whether Router B has sent a Report message to Router A. If no Report message is
sent, multicast entries cannot be created.
On Router A, run the debugging command. The command output shows that Router A has
received a Report message from Router B. Therefore, the possibility that the multicast entry
creation failure is caused by the Report message loss is excluded.
2. Router B triggers the SPT switchover after it learns (S, G) entries from the MSDP peer.
The detailed process is: Router A delivers multicast data packets to Router B. After
receiving the data packets from Router A, Router B triggers the SPT switchover. Router B
then updates the multicast routing table and forwarding table to ensure normal multicast
data packet forwarding. On Router B, run the display pim routing-table 239.253.154.4
command to check the incorrect entries. The following information shows one of the
incorrect entries:
Protocol: pim-sm, Flag: MSDP SWT

The preceding information indicates that:

l MSDP flag indicates that it is learnt from the MSDP peer.
l SWT flag indicates that the SPT switchover is in progress. After Router B receives
multicast data from the RPF interface, the SPT switchover is complete and entries are
marked with SPT.
SWT flag indicates that the SPT switchover is not complete. The entry is not marked
with ACT, no multicast data is received. This implies that the upstream Router A does
not forward any data to Router B.
3. Check the multicast routing table and forwarding table on Router A but find no incorrect
entry, that is, all parameters, including upstream interfaces and downstream interfaces are
correct.
4. Enabling port mirroring on Router A to capture all the packets on GE 1/0/0 and GE 2/0/0
will help to locate the fault; however, port mirroring is not supported for the outbound
traffic on non-Huawei devices. Therefore, packets on GE 2/0/0 that connects Router A to
Router B cannot be captured.
5. In addition, no packet is captured on GE 1/0/0 that connects Router A to the multicast
source. Therefore, where packets are lost cannot be located.
6. The problem is that Router A can properly create entries but cannot forward multicast data.
On Router B, run the reset multicast routing-table 239.253.154.4 command to reset the
entries related to the problem-involved multicast groups in the multicast routing table. The
fault persists and the multicast routing table and forwarding table on Router B cannot be
displayed through the display pim routing-table command and the display multicast
routing-table command.
7. Router B does not have any multicast routing table and forwarding table. Therefore, the
fault is not resulted from Router B. Then, reset the entry in the preceding command output
on Router A. After 30 seconds, entries are correctly created on Router B.
8. On Router A, reset the entries corresponding to the problem-involved multicast groups and
find that Router B generates correct entries for these groups. On-site engineers then test
the inaccessible channels and find that these channels recover. Therefore, it can be
concluded that the fault is caused by incorrect routes on the non-Huawei device.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 55

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Procedure
l A patch is provided to upgrade the non-Huawei device.

After the patch is installed, the inaccessible channels recover. The fault is cleared.

----End

Summary
Correct routes are a prerequisite for the normal running of multicast services.

2.8.10 PIM Inter-Domain MSDP Failed

Fault Symptom
As shown in Figure 2-16, each PIM-SM domain has two RPs and MSDP is run between RPs.
Anycast RP is used in each PIM domain and RPs are statically designated. In addition, MSDP
is deployed between PIM-SM2 and PIM-SM1, and between PIM-SM3 and PIM-SM1. PIM-
SM3 cannot obtain (S, G) information about the multicast source in PIM-SM2.

Figure 2-16 Networking diagram of PIM inter-domain MSDP

S1

PIM-SM1 Level-1

PIM-SM2 PIM-SM3
Level-2
Level-2

S1 S1

Fault Analysis
PIM-SM3 cannot receive (S, G) information about the multicast source. The possible cause may
be that (S, G) messages are discarded. Then, check the networking.

1. MSDP performs the RPF check after receiving SA messages to avoid loops.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 56

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2. PIM-SM2 originates SA messages and sends messages to PIM-SM1; PIM-SM1 then

forwards the messages to PIM-SM3. After receiving the SA messages, the MSDP peer in
PIM-SM3 finds that the source IP of the messages is not the next hop of the route to the
source's RP. The RPF check fails and the peer discards the messages.
3. PIM-SM1 originates SA messages and sends messages to PIM-SM3. Because the source's
RP address and the source IP of SA messages are the same, the RPF check succeeds and
PIM-SM3 can receive (S, G) messages from PIM-SM1.

Procedure
Step 1 There are three solutions to this problem.
l Fully connect all MSDP peers.
Advantage: After full connections are set up, RPF check succeeds and loops are avoided.
In addition, peers can rapidly respond to network changes.
Disadvantages: The number of MSDP peer connections are added. With the increase in
network nodes, configuration workloads are heavy.
This solution is recommended.
l Configure a static RPF peer relationship between the RP in PIM-SM3 and the RP in PIM-
SM1 to ensure that PIM-SM3 can properly receive SA messages.
Advantage: The configuration is simple. You only need to run the static-rpf-peer peer-
address [ rp-policy ip-prefix-name ] command to configure a static RPF peer relationship
between the RP in PIM-SM3 and the RP in PIM-SM1.
Disadvantage: Static configuration cannot rapidly respond to network changes.
l Establish an MBGP connection between MSDP peers in PIM-SM1 and PIM-SM3 to
advertise remote RP routes to PIM-SM3 through MBGP. This solution ensures correct RPF
check.
This solution is not recommended. Because there are services running on the network, MBGP
connections will cause the flapping of unicast BGP neighbor relationships.

----End

Summary
Full-connected MSDP peers ensure correct RPF check and avoid SA message flooding, thereby,
ensuring correctness of multicast entries.

In addition, to ensure RP reliability and node backup, there is no need to divide one AS into
multiple multicast domain. You only need to configure anycast RP on the nodes that need to set
up fully connected MSDP connections.

2.8.11 Multicast Traffic Failed to Be Transmitted Because MTUs on

Two Link Ends Are Inconsistent

Fault Symptom
As shown in Figure 2-17, Router A is a Huawei device and Router B is a non-Huawei device.
PIM is configured between Router A and Router B. After the configuration, some multicast
traffic failed to be forwarded.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 57

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-17 Networking diagram

GE1/0/0
GE2/0/0
RouterA RouterB

Fault Analysis
1. Run the display pim control-message counters interface-type interface-number
command on Router A and Router B to check the number of PIM control messages, and
find that the number of Join/Prune messages (displayed in the Join-prune field in the
command output) sent by GE 2/0/0 on Router B is greater than the number of Join/Prune
messages received by GE 1/0/0 on Router A. This indicates that some PIM messages are
lost on GE 1/0/0.
2. Run the display this command in the interface view to check the MTU of GE 2/0/0 on
Router B and MTU of GE 1/0/0 on Router A, and find that MTUs are inconsistent.
The cause of the problem is finally located: The number of Join/Prune messages sent by
GE 2/0/0 exceeded the MTU of GE 1/0/0 and Router A discarded the excessive messages.

Procedure
Step 1 Run the system-view command on Router A to enter the system view.

Step 2 Run the interface gigabitethernet 1/0/0 command to enter the GE 1/0/0 interface view.

Step 3 Run the mtu mtu command to adjust the MTU of GE 1/0/0. Ensure that the MTUs of two link
ends enabled with PIM are consistent. The fault is then solved.

----End

Summary
When interworking with non-Huawei devices, Huawei devices will check the interface MTU
after they receive PIM messages. The MTUs of two link ends should be consistent. When Huawei
devices communicate, MTU checking, however, is not needed.

PIM Join/Prune messages can be aggregated, that is, multiple source/group-specific Join/Prune
messages can be put into one packet and the packet size changes according the MTU and PIM
entries. If there are many entries and the MTU of the upstream interface of the downstream
device is relative large, the packet size may exceed the MTU of the downstream interface of the
upstream device, and the upstream device then discards the packet. The MTUs of the interfaces
connecting upstream and downstream interfaces must be consistent so that some packets will
not be discarded.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 58

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

2.8.12 A PE in a Multicast VPN in BGP A-D Mode Cannot Learn A-

D Routing Information from Remote Peers

Fault Symptom
As shown in Figure 2-18, a multicast VPN in BGP A-D mode is deployed, and CE1 and CE2
are connected to a multicast source and a multicast receiver respectively. After completing the
preceding configurations, PE1 and PE2 cannot learn A-D routing information from each other.

Figure 2-18 Networking for the multicast VPN in BGP A-D mode
Source
VPN Receiver
BLUE
VPN
BLUE
CE1

PE1 Public
CE2

PE2
P

Fault Analysis
1. Run the display current-configuration command on PE1 and PE2 to check whether the
A-D modes configured in VPN BLUE are consistent. The command output shows that the
A-D modes are consistent.
2. Run the display current-configuration command on PE1 and PE2 to check whether the
address family configured in the BGP view matches the address family configured for the
A-D mode in the VPN instance IPv4 address family view. The command output shows that
the address family configured in the BGP view does not match the address family
configured for the A-D mode in the VPN instance IPv4 address family view. Therefore,
BGP will not advertise or learn A-D routing information of this address family.

Do as follows on PE1 and PE2 to rectify the fault.

Procedure
Step 1 Run the system-view command to enter the system view.

Step 2 Run the bgp { as-number-plain | as-number-dot } command to enter the BGP view.

Step 3 Run the ipv4-family mdt command to enter the BGP-MDT address family view.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 59

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Step 4 Run the peer { group-name | ipv4-address } enable command in the BGP-MDT view to enable
routing information exchange between specified BGP peers.

Step 5 Run the quit command to exit from the BGP-MDT view.

Step 6 Run the quit command to exit from the BGP view.

Step 7 Run the ip vpn-instance vpn-instance-name command to enter the VPN instance view.

Step 8 Run the ipv4-family command to enable the IPv4 address family for the VPN instance and enter
the VPN instance IPv4 address family view.

Step 9 Run the auto-discovery mdt command to configure the MDT-SAFI A-D mode in the VPN
instance IPv4 address family view.

Step 10 Run the return command to return to the user view, and run the save command to save the
modification.

After completing the preceding steps, run the display multicast-domain vpn-instance vpn-
instance-name share-group remote command on PE1 and PE2. The command output shows
that they can learn A-D routing information from each other. The fault is rectified.

----End

Summary
When configuring the BGP A-D function on PEs to implement communication in a multicast
VPN, ensure that the address family configured in the BGP view matches the address family
configured for the A-D mode in the VPN instance IPv4 address family view.

2.8.13 A PIM Neighbor Relationship Cannot Be Established in a

Multicast VPN in BGP A-D Mode Because the Configured Share-
Group Address Is Beyond the SSM Group Address Range

Fault Symptom
As shown in Figure 2-19, a multicast VPN in BGP A-D mode is deployed, and CE1 and CE2
are connected to a multicast source and a multicast receiver respectively. After completing the
preceding configurations, PE1 and PE2 can learn A-D routing information from each other but
cannot establish a PIM neighbor relationship.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 60

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-19 Networking for a multicast VPN in BGP A-D mode

Source
VPN Receiver
BLUE
VPN
BLUE
CE1

PE1 Public
CE2

PE2
P

Fault Analysis
1. Check the SSM group address range.
Run the display current-configuration command on PE1 and PE2 to check whether an
SSM-policy is configured. The default SSM group address range is 232.0.0.0/8. The ssm-
policy { acl-number | acl-name acl-name } command can also be used to set the SSM
group address range. Therefore, the SSM group address range is determined by the default
SSM group address range together with that set through the command.
NOTE

Whether the share-group address carried in the A-D routing information learned by the remote PE
is in the SSM group address range depends on the SSM-policy on the local PE but not on the
configuration on the remote PE.
2. Check whether the share-group address is in the SSM group address range.
Run the display multicast-domain vpn-instance vpn-instance-name share-group
command on PE1 and PE2. The command output shows that the share-group address
configured on the local PE is beyond the SSM group address range.

Do as follows on PE1 and PE2 to rectify the fault.

Procedure
Step 1 Run the system-view command to enter the system view.

Step 2 Run the ip vpn-instance vpn-instance-name command to enter the VPN instance view.

Step 3 Run the ipv4-family command to enable the IPv4 address family for the VPN instance and enter
the VPN instance IPv4 address family view.

Step 4 Run the multicast-domain share-group group-address binding mtunnel number command to
configure a share-group address and specify the MTIs to be bound to the VPN instance.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 61

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

NOTE

The share-group address must be in the SSM group address range.

Step 5 Run the return command to return to the user view, and run the save command to save the
modification.

After completing the preceding steps, run the display pim vpn-instance vpn-instance-name
neighbor command on PE1 and PE2. The command output shows that a PIM neighbor
relationship has been established. The fault is rectified.

----End

Summary
The share-group addresses set on PEs in the multicast VPN in BGP A-D mode must be in the
SSM group address range.

2.8.14 A Receiver on a Multicast VPN Extranet-enabled Network

Cannot Receive Multicast Data from a Source VPN

Fault Symptom
On the network shown in Figure 2-20, CE1 and CE3 belong to difference VPN instances, and
the multicast VPN Extranet service is configured to enable CE1 and CE3 to communicate with
each other. After completing the preceding configurations, users attached to CE3 fail to receive
multicast data from the source in VPN RED.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 62

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

Figure 2-20 Networking for multicast VPN Extranet

Source
VPN Source
RED
VPN
CE1 BLUE

IP MPLS Core
PE1 CE2

P PE2

PE3

CE3

VPN
BLUE

Receiver

Fault Analysis
1. Run the display pim vpn-instance BLUE routing-table command on PE3. The command
output shows that no PIM entries have been created. Check the PIM-SM configurations. If
the configurations are incorrect, a multicast distribution tree cannot be set up. If the
configurations are correct, view the maximum number of PIM entries defined in the license
file and check whether the number of current (*, G) or (S, G) entries exceeds the maximum
number. If the number of entries exceeds the maximum number, new entries cannot be
created.
2. Run the display ip routing-table vpn-instance BLUE command on PE3 to check whether
the route from VPN BLUE to the multicast source exists. If there is no route from VPN
BLUE to the multicast source, packet forwarding fails.
3. Run the display current-configuration command on each device to check whether each
of the source and receiver VPN instances has at least one PIM-SM-enabled interface. This
is a prerequisite for implementing multicast VPN Extranet.
4. Run the display ip routing-table vpn-instance RED command on PE1 to check whether
the route from VPN RED to the multicast source exists.
l If there is no route from VPN RED to the multicast source, create such a route.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 63

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

l If there is a route from VPN RED to the multicast source, check whether VPN BLUE
has correctly imported the route of VPN RED and whether MPLS/BGP VPN is
configured correctly.
5. Run the display ip routing-table vpn-instance BLUE command on PE3. The command
output shows that there is a route to the multicast source. The display pim vpn-instance
BLUE routing-table command output, however, shows that the upstream of the PIM entry
is blank. Run the display pim vpn-instance BLUE routing-table command on PE3 to
check whether a multicast routing policy is configured for VPN BLUE. If no multicast
routing policy is configured or the configuration of the multicast routing policy is incorrect,
the upstream interface cannot be found and PIM entries cannot be correctly created.
6. Run the display pim vpn-instance BLUE routing-table command on PE3. The command
output shows that the upstream of the PIM entry is a multicast VPN Extranet interface
(VPN RED). PE3, however, still cannot receive multicast data. Then, check whether VPN
RED is configured correctly.
7. Run the display pim vpn-instance BLUE routing-table command on PE3. The command
output shows that the upstream of the PIM entry is a multicast VPN Extranet interface
(VPN RED). PE3, however, still cannot receive multicast data. Run the display
multicast vpn-instance RED forwarding-table command on PE1. The command output
shows that the downstream interface list does not contain VPN BLUE, and the number of
receiver VPN instances has reached the upper limit. Run the display multicast vpn-
instance RED routing-table command. The command output shows that the downstream
interface list contains the VPN BLUE. This indicates that the number of receiver VPN
instances has reached the upper limit that can be delivered by the forwarding plane. The
source can send multicast data to new receiver VPN instances only after some receiver
VPN instances quit the group.

Procedure
Step 1 Run the system-view command to enter the system view.
NOTE

Do as follows on the receiver PE if the source VPN instance is configured on the receiver PE in the remote-
cross scenario:

Step 2 Run the ip vpn-instance vpn-instance-name command to enter the VPN instance view.

Step 3 Run the ipv4-family view to enter the VPN instance IPv4 address family view.

Step 4 Run the multicast extranet select-rpf { vpn-instance vpn-instance-name | public } group
group-address { group-mask | group-mask-length } command to configure a multicast routing
policy that sets another VPN instance to be the upstream of the PIM entry of a specified multicast
group address.

After completing the preceding configurations, users attached to CE3 can receive multicast data
from the source.

----End

Summary
l In the remote-cross scenario of multicast VPN Extranet, if the scheme of configuring the
source VPN instance on the receiver PE is used, a multicast routing policy must be

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 64

Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine40E/80E Universal Service Router
Troubleshooting - IP Multicast 2 L3 Multicast

configured to enable the receiver VPN instance to send Join requests to the source VPN
instance and receive multicast data from a source properly.
l In the remote-cross scenario of multicast VPN Extranet, if the scheme of configuring the
receiver VPN instance on the source PE is used, no multicast routing policy needs to be
configured. If a multicast routing policy is configured, the source VPN instance defined in
the policy must be the source VPN instance from which the receiver PE expects to receive
multicast data. Otherwise, the receiver PE cannot receive multicast data properly.

Issue 03 (2013-08-20) Huawei Proprietary and Confidential 65

Copyright Huawei Technologies Co., Ltd.