No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade
TechNotes-Understanding and Configuring Multicast Simulation 01
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
TechNotes-Understanding and Configuring Multicast Simulation

TechNotes-Understanding and Configuring Multicast Simulation

A multicast emulation test remotely emulates an end user going online, and engineers query the real-time traffic of the multicast program to determine whether the multicast function is running properly.

Introduction

In multicast emulation, an access device remotely emulates an end user going online. Engineers query the real-time traffic of the multicast program to determine whether the multicast function is running properly.

Multicast emulation is used in acceptance tests or fault location. The following table lists the comparison between the multicast emulation test and traditional tests.
Table 1-1 Comparison between the multicast emulation test and traditional tests

Scenario

Task

Traditional Test

Multicast Emulation

Acceptance test

After an access device is installed and configured with data, a test engineer needs to check whether the multicast service has been provisioned to the access device successfully.

The test engineer visits the site where the access device is installed and uses an external tester or a portable computer to perform a multicast test on each port of the device.

The test engineer remotely logs in to the access device to perform a multicast emulation test and determines the service status based on the test results.

Fault location

The multicast service is abnormal, and a maintenance engineer needs to quickly locate the network segment of the fault to facilitate subsequent troubleshooting.

The maintenance engineer visits all sites where the access devices are installed and performs tests.

The maintenance engineer remotely logs in to an access device and performs a multicast emulation test to preliminarily determine the network segment of the fault. Based on the test results, the engineer diagnoses the fault cause and rectifies the fault.
NOTE:

A multicast emulation test cannot check the status of the line between an end user and an access device.

Principles

Figure 1-1 shows the principles of multicast emulation.
Figure 1-1 Principles of multicast emulation

  1. A maintenance engineer remotely logs in to an access device and starts a multicast emulation test on a user port.

    The engineer sets parameters, such as the user information, program IP address, and multicast VLAN ID.

  2. The access network device constructs a join packet and sends the packet to the multicast router for joining a multicast group.
  3. The multicast router checks whether the multicast program traffic exists.
    • If the multicast program traffic exists, the multicast router sends the multicast program traffic to the access device.
    • If the multicast program traffic does not exist, the multicast source sends the multicast program traffic to the access device after exchanging data with the multicast router.
  4. The maintenance engineer queries the status of the emulation user and the real-time traffic of the multicast program.
    • Checks whether the multicast emulation user is online to determine whether the user successfully orders the program.
    • Checks the real-time traffic of the multicast program to determine whether the communication between the access device and the multicast source is normal.
  5. After the multicast emulation is complete, the maintenance engineer stops the emulation manually using the CLI to release resources.

Usage Scenario

Context

On fiber to the x (FTTx) networks, access devices are located closer to user terminals and widely distributed. In a multicast emulation test, an access node emulates the multicast user to implement remote acceptance for services and locate faults, which reduces the O&M costs.

Scenario

Figure 1-2 shows the multicast emulation on a typical FTTx network.
Figure 1-2 Multicast emulation on a typical FTTx network

NOTE:

In Figure 1-2, the MDU and ONT can provide the video on demand (VoD) service for a user through the PC. The MDU and ONT can also provide the BTV service using a set top box (STB).

In IPTV service acceptance or fault location:
  • For MDU multicast users, multicast emulation can be performed on the MDU in service acceptance.
  • For ONT multicast users, multicast emulation can be performed on the OLT.
    NOTE:

    ONTs do not support multicast emulation. To emulate an ONT multicast user, perform an emulation test on the PON board of the OLT.

Figure 1-3 illustrates the typical usage scenario of multicast emulation in DSLAM networking.
Figure 1-3 Typical usage scenario of multicast emulation in DSLAM networking

In IPTV service acceptance or fault location, multicast emulation can be performed on the DSLAM for the multicast users connected to the DSLAM.

Fault Location

After the multicast emulation, you can query the user status and multicast program's real-time traffic through the CLI. The following table lists troubleshooting suggestions based on the query results.
NOTE:

Data configurations are seldom changed in daily operation and maintenance. Therefore, multicast faults are usually caused by hardware problems. Hardware must be checked prior to data configuration during fault location.

Table 1-2 Multicast emulation results and troubleshooting suggestions

Command

Results

Description

Troubleshooting Suggestions

display igmp user

The user status parameter State is online.

The multicast user can go online successfully.

  • If the user can go online and the access device can communicate with the multicast source, the fault may be caused by a communication failure between the access device and the set-top box (STB). The reasons are as follows:
    • The hardware of the port on the access device is faulty.
    • The physical line between the access device and the modem is faulty.
    • The modem is faulty.
    • The STB is faulty.
  • If the user can go online but the traffic on the access device's uplink port is abnormal, the fault may be that the hardware connection between the access device and the upper-layer device (multicast router or multicast server) is incorrect, or the software configuration is incorrect.

    The common software configuration faults are as follows:

    • The remaining multicast bandwidth of the user is lower than the required bandwidth of the ordered program.
    • The number of programs watched by the multicast user reaches the upper limit so that the user cannot order a new program.
    • The multicast user does not have the permission to watch the program.
    • The program ordered is not in the MVLAN to which the multicast user belongs.
    • The multicast user does not have the permission to order certain types of programs (such as HDTV).
    • The number of programs at a level watched by the multicast user reaches the upper limit so that the user cannot order a new program at this level.
    • The rate configured in the traffic profile bound to the traffic stream is far lower than the bandwidth of the multicast program.
    • There are too many prejoined static programs, occupying too many bandwidths.

    The common software configuration problems of the upper layer device are as follows:

    • The program is not configured on the multicast server.
    • The TTL value set on the multicast server for the multicast stream is very small.

The user status parameter State is offline.

The multicast user fails to go online and therefore fails to order a program in the emulation.

The case is more complicated than the scenario in which the user is online. Handling suggestions are as follows: Enable the multicast debugging function and start the multicast emulation again to check whether the access device receives the report packet from the user for ordering a program. Run the following commands to enable the multicast debugging function:

huawei(config)#terminal debugging
huawei(config)#terminal monitor
huawei(config)#debugging igmp service-port index
NOTE:

index is the ID of the multicast user's service port.

  • If the access device receives the report packet, the multicast link is normal but the access device fails to create a corresponding multicast entry. This is generally caused by incorrect multicast configurations on the access device.
  • If the access device does not receive the report packet, the multicast link fails. This is mainly caused by incorrect access device data configurations, faulty physical link between the access device and the modem, or hardware faults of terminals.

The user status parameter State is block.

The multicast user is locked and therefore fails to order a program.

Run the undo igmp user block command to unblock the unblock the user.

display multicast flow-statistic

The multicast program's real-time traffic parameter Multicast flow statistic result is a small value or zero.

The program's traffic on the uplink port is small or zero.

The hardware connection between the access device and the upper-layer device (multicast router or multicast server) is incorrect, or the software configuration is incorrect. troubleshoot the fault based on the suggestions provided when the user can go online but the traffic on the access device's uplink port is abnormal.

The multicast program's real-time traffic parameter Multicast flow statistic result is close to the program's bandwidth.

The device uplink port can communicate with the multicast source.

  • If the user can go online and the access device can communicate with the multicast source, the fault may be caused by a communication failure between the access device and the STB. The reasons are as follows:
    • The hardware of the port on the access device is faulty.
    • The physical line between the access device and the modem is faulty.
    • The modem is faulty.
    • The STB is faulty.
  • If the access device can communicate with the multicast source but the user cannot go online, troubleshoot the fault based on the suggestions provided when the user status parameter State is offline.

Configuration

Context

  • The configuration of the multicast port is correct.
  • The multicast user for whom the multicast emulation test is performed has the rights to watch the configured multicast programs.

Procedure

  1. Run the igmp static-join command to perform the multicast emulation test for the multicast user.

    huawei(config)#btv
    huawei(config-btv)#igmp static-join service-port 500
    { ip<K>|ipv6<K> }:ip
    { ip-addr<I><X.X.X.X> }:224.1.1.1
    { vlan<K> }:vlan
    { vlanid<U><1,4093> }:4002

  2. Run the display igmp user command to query the status of the multicast user.

    • If the multicast user is in offline state, the multicast user fails to request for programs.
    • If the multicast user is in online state, the multicast user requests for programs successfully.
    • If the multicast user is in block state, the multicast user is blocked. In this case, run the undo igmp user block command to unblock the user.
    huawei(config)#display igmp user service-port 500
      User                       : 0/1/0
    State: online // The multicast user is online.
      Authentication             : auth
      Quick leave                : MAC-based
      IGMP flow ID               : 500
      Video flow ID              : 500
      Log switch                 : enable
      Bind profiles              : 2
      IGMP version               : IGMP v3
      Current version            : IGMP v3
      ......
    

  3. Run the display multicast flow-statistic command to query the real-time traffic of the programs that the multicast user requests for in the multicast emulation test.

    • If the real-time traffic of the multicast programs is a smaller value or 0, the multicast source does not deliver multicast programs or the multicast service stream does not arrive at the device. That is, the communication between the device and the multicast source is abnormal.
    • If the real-time traffic of the multicast programs approaches the bandwidth of the multicast programs, the multicast source delivers the multicast programs to the device. That is, the communication between the device and the multicast source is normal.
    huawei(config)#btv
    huawei(config-btv)#display multicast flow-statistic vlan 4002 ip 224.1.1.1
      Command is being executed, please wait...
      Multicast flow statistic result: 29600(kbps)    //The real-time traffic of multicast program 224.1.1.1 is 29600 kbit/s. This indicates that the multicast source issues multicast traffic.

  4. Run the undo igmp static-join command to stop multicast emulation.

    huawei(config)#btv
    huawei(config-btv)#undo igmp static-join service-port 500
    { ip<K>|ipv6<K> }:ip
    { ip-addr<I><X.X.X.X> }:224.1.1.1
    { vlan<K> }:vlan
    { vlanid<U><1,4093> }:4002

Reference Standards and Protocols

  • RFC-2236: Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997
  • RFC 3376: B. Cain., "Internet Group Management Protocol, Version 3", RFC 3376, October 2002
  • RFC 4607: H. Holbrook, "Source-Specific Multicast for IP", RFC 4607, August 2006
Translation
Download
Updated: 2019-09-27

Document ID: EDOC1100106596

Views: 446

Downloads: 71

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Share
Previous Next