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

ME60 Troubleshooting Guide V1.0 (VRPv8)

This document provides the maintenance guide of the device, including daily maintenance, emergence maintenance, and typical troubleshooting.
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).
IP Multicast

IP Multicast

This chapter describes common causes of IP multicast faults and provides troubleshooting flowcharts and procedures, alarms, and logs to help identify and rectify these faults.

Multicast Traffic Fails to Be Transmitted

This section describes how to troubleshoot IP multicast traffic transmission failures.

Common Causes

Common causes are as follows:

  • Route configurations are incorrect.
  • VLAN or VSI status is incorrect.
  • Multicast configurations are not delivered.
  • Protocol entries are not generated.
  • Upper-layer forwarding entries are not generated.
Troubleshooting Flowchart

The troubleshooting roadmap is as follows:
  • Check that routes to a multicast source are reachable.
  • Check that a PIM information table has been generated.
  • Check that forwarding entries have been generated.

Figure 4-70 shows the troubleshooting flowchart.

Figure 4-70 Flowchart for troubleshooting multicast traffic transmission failures

Troubleshooting Procedure

Context

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Check that a route is reachable to the multicast source.

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

    NOTE:

    ip-address specifies a multicast source address.

    • If a reachable route does not exist, configure one.

    • If a reachable route exists, go to Step 2.

  2. Check that a PIM information table has been generated.

    Run the display pim routing-table command to check whether a PIM information table has been generated.

    • If no entries are displayed, check whether PIM configurations are correct.

      • If the PIM configurations are correct, go to Step 3.

      • If the PIM configurations are incorrect, remove configuration errors.

    • If entries are displayed, go to Step 3.

  3. contact technical support personnel and provide the following information:
    • Results of this troubleshooting procedure

    • Configuration files, log files, and alarm files

Relevant Alarms and Logs

Relevant Alarms

None

Relevant Log

None

A PIM Neighbor Relationship Remains Down

This section describes how to troubleshoot PIM neighbor relationship Down faults.

Common Causes

Common causes are as follows:

  • An interface is physically Down, or an interface's link-layer protocol status is Down.

  • PIM is not enabled on an interface.

  • PIM configurations on an interface are incorrect.

Troubleshooting Flowchart

Figure 4-71 shows the troubleshooting flowchart.

Figure 4-71 Flowchart for troubleshooting PIM neighbor relationship Down faults

Troubleshooting Procedure

Context

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Check that PIM is enabled on an interface.

    Run the display current-configuration interface interface-type interface-number command to check whether PIM is enabled on an interface.

    • If PIM is not enabled, enable it.

      If PIM fails to be enabled and the system displays "Error: Please create Multicast Enable first, because current configuration depends on the object", run the multicast routing-enable command in the system view to enable the multicast routing function. Then, enable PIM-SM on the interface.

    • If PIM is enabled, go to Step 2.

  2. Check that PIM is Up on the interface.

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

    • If PIM 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, change the physical status to Up.

      2. If the link status is not Up, change the link status to Up.

    • If PIM is Up, go to Step 3.

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

    The following PIM configurations may cause the fault:
    • The IP addresses of directly connected interfaces are on different network segments.

    • A PIM neighbor filtering policy is configured on the interface, and the address of the PIM neighbor is filtered out by the policy.

    • Hello messages sent by PIM neighbors do not carry Generation IDs, but the interface denies Hello messages that do not carry Generation IDs. This situation often occurs if a Huawei device connects to non-Huawei devices.

    Run the display current-configuration interface interface-type interface-number command to check whether any of the preceding PIM configurations exists on the interface.

    • If any of the preceding PIM configurations exists, modify it.

    • If no preceding PIM configurations exist, go to Step 4.

  4. contact technical support personnel and provide the following information:

    • Results of this troubleshooting procedure
    • Configuration files, log files, and alarm files

Relevant Alarms and Logs

Relevant Alarms

None

Relevant Log
PIMPRO/4/NBR_LOSS

An RPT Fails to Forward Data on a PIM-SM Network

This section describes how to troubleshoot data forwarding failures on a PIM-SM RPT.

Common Causes

Common causes are as follows:

  • No unicast routes are reachable from a multicast device to an RP.

  • Different RP addresses are set on multicast devices.

  • A multicast device's downstream interface does not receive (*, G) Join messages.

  • PIM-SM is not enabled on interfaces.

  • An RPF route to an RP is incorrect, such as a loop unicast route.

  • Configurations are incorrect, such as incorrect configurations of TTLs, MTUs, and multicast boundaries.

Troubleshooting Flowchart

Figure 4-72 shows the troubleshooting flowchart.

Figure 4-72 Flowchart for troubleshooting data forwarding failures on a PIM-SM RPT

Troubleshooting Procedure

Context

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

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

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

    • If (*, G) entries exist and are all correct, check whether the forwarding table contains (S, G) entries associated with the (*, G) entries and the value of the Matched field keeps increasing every 15 seconds in the command output.

      • If the forwarding table contains associated (S, G) entries and the value of the Matched field keeps increasing, the upstream device can normally forward multicast data to the local device but the local device fails to forward the data to its downstream device. This failure may be because the TTL value is small or forwarding errors exist.

      • If the forwarding table does not contain associated (S, G) entries or the value of the Matched field remains unchanged, perform the following operations:
        • If the local device is not an RP, the local device has not received any multicast data. The fault may be caused by the upstream device. Check whether the PIM routing table on the upstream device contains correct (S, G) entries.

        • If the local device is an RP, the RPT has been set up, but the RP fails to receive multicast data from the multicast source. The fault may be caused by source's DR registration failures. Then, go to Step 11.

    • If the PIM routing table does not contain correct (*, G) entries, go to Step 2.

  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 Join/Prune messages received by the downstream interface keeps increasing.

    • If the number of received Join/Prune messages 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 to its upstream device.
      • If the number of sent Join/Prune messages keeps increasing, the downstream device has sent Join/Prune messages. The fault may be caused by PIM neighbor communication failures. Go to Step 11.

      • If the number of sent Join/Prune messages does not increase, the downstream device is faulty. Locate and rectify faults on the downstream device.

    • If the number of received Join/Prune messages keeps increasing, go to Step 3.

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

    An operator easily ignores the following interfaces when enabling PIM-SM:
    • RPF neighboring interface towards an RP

    • RPF interface towards an RP

    • Interface directly connected to user hosts' network segment (downstream interface of a receiver's DR)

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

    • If an interface's information is not displayed in the command output, run the pim sm command to enable PIM-SM on the interface.

      If the system displays "Error: Please create Multicast Enable first, because current configuration depends on the object." when you attempt to enable PIM-SM on the interface, run the multicast routing-enable command in the system view to enable the multicast routing function and then enable PIM-SM on the interface.

    • If PIM-SM is enabled on all interfaces, go to Step 4.

  4. Check that the RP information is correct.

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

    • If no RP information is displayed or if the RP information is different from that on other devices, perform the following operations:
      • If a static RP is used, run the static-rp command on all devices to configure the same RP address for a specific multicast group.

      • If a dynamic RP is used, go to Step 11.

    • If the RP information is the same as that on other devices, go to Step 5.

  5. Check that an RPF route is reachable to the RP.

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

    • If no RPF routes are reachable to the RP, check unicast route configurations. Run the ping command on the local device and the RP to check whether they can ping each other.

    • If an RPF route is reachable to the RP, perform the following operations:
      • If the RPF route is a static multicast route or an MBGP route, run the display current-configuration command to check whether the route configuration is proper.

      • If the RPF route is a unicast route, run the display ip routing-table command to check whether the route is the same as the RPF route.

    • If an RPF route is reachable to the RP and the route configuration is proper, go to Step 6.

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

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

    • If local is not displayed in the DR-Address field, perform these troubleshooting operations to rectify faults on the DR device that has the address in the command output.

    • If local is displayed in the DR-Address field, go to Step 7.

  7. Check that no TE tunnel interfaces are configured as RPF route's outbound interfaces.

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

    Multicast routing is the reverse of unicast routing. TE tunnels are unidirectional and do not support multicast routing.

    • If the RPF route's outbound interface is a TE tunnel interface, enable the local MT feature or change the static multicast route configurations to ensure that a TE tunnel interface is not used as the RPF route's outbound interface.

    • If the RPF route's outbound interface is not a TE tunnel interface, go to Step 8.

  8. Check that no multicast boundary is configured on an interface.

    Run the display current-configuration interface interface-type interface-number command to check whether a multicast boundary is configured on an interface.

    • If multicast boundary is displayed for an interface, a multicast boundary is configured on the interface. Run the undo multicast boundary { group-address { mask | mask-length } | all command to delete the multicast boundary configuration or modify configurations to ensure that no multicast boundary is configured on RPF interfaces or on RPF neighboring interfaces.

    • If no multicast boundary is configured on an interface, go to Step 9.

  9. Check that no source policy is configured.

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

    • If source-policy acl-number is displayed, a source-based filtering policy is configured. If the ACL rule denies received multicast data, run the undo source-policy command to delete the ACL rule configuration or reconfigure an ACL rule that allows requested multicast data to be forwarded.

    • If no source policy is configured, go to Step 10.

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

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

  11. If the fault persists after this troubleshooting procedure is complete, contact technical support personnel.
Relevant Alarms and Logs

Relevant Alarms

None

Relevant Log

None

An SPT Fails to Forward Data on a PIM-SM Network

This section describes how to troubleshoot data forwarding failures on a PIM-SM RPT.

Common Causes

Common causes are as follows:

  • A multicast device's downstream interface does not receive (S, G) Join messages.

  • PIM-SM is not enabled on interfaces.

  • An RPF route to an RP is incorrect, such as a loop unicast route.

  • Configurations are incorrect, such as incorrect configurations of TTLs, MTUs, switchover thresholds, and multicast boundaries.

Troubleshooting Flowchart

Figure 4-73 shows the troubleshooting flowchart.

Figure 4-73 Flowchart for troubleshooting data forwarding failures on a PIM-SM SPT

Troubleshooting Procedure

Context

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

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

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

    • If the PIM routing table contains correct (S, G) entries, perform the following operations:
      • Check whether an entry has an SPT flag.
        • The RP has received Register messages from the source's DR but an SPT is not established if the following conditions are met: A multicast group address is in the ASM group address range, an SPT switchover is triggered by the RP, and the RP's upstream interface is a register interface. To resolve this problem, contact technical support personnel.

        • An SPT is not established if the following conditions are met: A multicast group address is in the ASM group address range, an SPT switchover is triggered by the receiver's DR, and the upstream interface is an RPF interface towards the RP not the multicast source. To resolve this problem, perform the following operations:

          Run the display current-configuration configuration pim command on the receiver's DR to view configurations in the PIM view. If the command output contains spt-switch-threshold traffic-rate or spt-switch-threshold infinity, run the undo spt-switch-threshold command to delete traffic rate configurations or run the undo spt-switch-threshold traffic-rate command to reconfigure a proper traffic rate.

      • Check whether the downstream interface list contains downstream interfaces that forward data to all group members.

        If (S, G) entries exist and are all correct in the PIM routing table, view the (S, G) entries in the forwarding table, and check whether the value of the Matched field keeps increasing.

        • If the value of the Matched field keeps increasing, the upstream device can normally forward multicast data to the local device, but the local device fails to forward the data to its downstream device. Go to Step 10.

        • If the value of the Matched field remains unchanged and If the local device is not a source's DR, the local device has not received any multicast data. The fault may be caused by the upstream device. 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 correct (S, G) entries, locate faults on the upstream device by performing operations in the troubleshooting procedure.

          • If the PIM routing table on the upstream device contains correct (S, G) entries but the value of the Matched field remains unchanged, go to Step 10.

        • If the value of the Matched field remains unchanged and If the local device is a source's DR, an SPT has been set up but the source's DR fails to forward multicast data along the SPT. Go to Step 10.

    • If the PIM routing table does not contain correct (S, G) entries, go to Step 2.

  2. Check whether the downstream interface has received Join messages.

    NOTE:

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

    If the downstream interface does not receive any (S, G) Join messages, possible causes are as follows:
    • A fault has occurred on the downstream interface.

    • 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 Join/Prune messages received by the downstream interface keeps increasing.

    • If the number of received Join/Prune messages 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 any Join/Prune messages to its upstream device.
      • If the number of sent Join/Prune messages keeps increasing, the downstream device has sent Join/Prune messages. The fault may be caused by PIM neighbor communication failures. To troubleshoot this fault, go to Step 10.

      • If the number of sent Join/Prune messages does not increase, the downstream device is faulty. Locate and rectify faults on the downstream device.

    • If the number of Join/Prune messages received by the downstream interface keeps increasing, go to Step 3.

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

    An operator easily ignores the following interfaces when enabling PIM-SM:
    • RPF neighboring interface towards a multicast source

    • RPF interface towards a multicast source

    NOTE:

    In PIM-SM network deployment, enable the multicast routing function on all devices and enable PIM-SM on all interfaces.

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

    • If an interface's information is not displayed in the command output, run the pim sm command on the interface.

      If the system displays "Error: Please create Multicast Enable first, because current configuration depends on the object." when you attempt to enable PIM-SM on the interface, run the multicast routing-enable command in the system view to enable the multicast routing function and then enable PIM-SM on the interface.

    • If PIM-SM is enabled on all interfaces, go to Step 4.

  4. Check that an RPF route is reachable to a multicast source.

    Run the display multicast rpf-info source-address command to check whether an RPF route is reachable to a multicast source.

    • If no RPF routes are reachable to the multicast source, check unicast route configurations. Run the ping command on the local device and the RP to check whether they can ping each other.

    • If an RPF route is reachable to the multicast source, perform the following operations:
      • If the RPF route is a static multicast route or an MBGP route, run the display current-configuration command to check whether the route configuration is proper.

      • If the RPF route is a unicast route, run the display ip routing-table command to check whether the route is the same as the RPF route.

    • If an RPF route is reachable to the source and the route configuration is proper, go to Step 5.

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

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

    • If local is not displayed in the DR-Address field, perform operations in the troubleshooting procedure to locate and rectify faults on the DR that has the address in the command output.

    • If local is displayed in the DR-Address field, go to Step 6.

  6. Check that no TE tunnel interfaces are configured as RPF route's outbound interfaces.

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

    Multicast routing is based on the RPF check, but the TE tunnel is unidirectional. Therefore, TE tunnels do not apply to the multicast scenario.

    • If the RPF route's outbound interface is a TE tunnel interface, enable the local MT feature or change the static multicast route configurations to ensure that a TE tunnel interface is not used as the RPF route's outbound interface.

    • If the RPF route's outbound interface is not a TE tunnel interface, go to Step 7.

  7. Check that no multicast boundary is configured on an interface.

    Run the display current-configuration interface interface-type interface-number command to check whether a multicast boundary is configured on an interface.

    • If multicast boundary is displayed for an interface, a multicast boundary is configured on the interface. Run the undo multicast boundary { group-address { mask | mask-length } | all command to delete the multicast boundary configuration or modify configurations to ensure that no multicast boundary is configured on RPF interfaces or on RPF neighboring interfaces.

    • If no multicast boundary is configured on an interface, go to Step 8.

  8. Check that no source policy is configured.

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

    • If source-policy acl-number is displayed, a source-based filtering policy is configured. If the ACL rule denies received multicast data, run the undo source-policy command to delete the ACL rule configuration or reconfigure an ACL rule that allows requested multicast data to be forwarded.

    • If no source policy is configured, go to Step 9.

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

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

  10. If the fault persists after these troubleshooting steps are complete, contact technical support personnel.
Relevant Alarms and Logs

Relevant Alarms

None

Relevant Log

None

MSDP Peers Cannot Generate Correct (S, G) Entries

This section describes how to troubleshoot (S, G) entry generation failures on MSDP peers.

Common Causes

Common causes are as follows:

  • MSDP peers that initiate SA messages are not configured on an RP.

  • A logical RP is not configured or is configured incorrectly on Anycast-RP devices.

  • An MSDP peer relationship is not set up between each two members in a mesh group.

  • PIM-SM is not used as the intra-domain multicast protocol.

  • An RPF route to an RP is incorrect, such as a loop unicast route.

  • Configurations are incorrect, such as incorrect configurations of SA policies, import policies, TTLs, switchover thresholds, and multicast boundaries.

  • SA messages fail to pass an RPF check.

Troubleshooting Flowchart

Figure 4-74 shows the troubleshooting flowchart.

Figure 4-74 Flowchart for troubleshooting (S, G) entry generation failures on MSDP peers

Troubleshooting Procedure

Context

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Check that MSDP peers are both Up.

    Run the display msdp brief command to check whether each MSDP peer is Up.

    • If the MSDP peers are Down, check whether the MSDP peer interfaces are configured correctly and whether the MSDP peers can ping each other.

    • If the MSDP peers are both Up, go to Step 2.

  2. Check that SA cache is enabled.

    Run the display this command on the MSDP peers to view configurations in the MSDP view.

    • If undo cache-sa-enable is displayed, SA cache is disabled. Run the cache-sa-enable command in the MSDP view to enable SA cache.

    • If SA cache is enabled, go to Step 3.

  3. Check that the MSDP peers have received SA messages.

    Run the display msdp sa-count command on the MSDP peers to check contents in the SA cache.

    • If no information is displayed, run the display msdp peer-status command to check whether the Count of RPF check failure field value is 0.
      • If the field value is not 0, check whether RPF routes are configured correctly.

      • If the field value is 0, check the Incoming/outgoing SA messages field value to determine whether SA messages have been received.

        • If no SA messages are received, check whether the mesh group is configured correctly.

        • If SA messages are received, go to Step 5.

    • If the value of the Number of source or Number of group field is not 0, the MSDP peers have received SA messages. Go to Step 4.

  4. Check that no export policies are configured on the MSDP peers.

    Run the display this command on the MSDP peers to view configurations in the MSDP view.

    • If export policies are configured on the MSDP peers, perform the following operations:
      • If the peer peer-address sa-policy export command is run and no parameters are specified, the MSDP peers do not forward messages received from the multicast source. Run the undo peer peer-address sa-policy export command to delete the export policy configuration.

      • If the peer peer-address sa-policy export command is run and the acl advanced-acl-number or peer peer-address sa-policy export acl acl-name parameter is specified, the MSDP peers forward only (S, G) entries permitted by the ACL. Check whether the ACL is configured on the MSDP peers and whether the (S, G) entries are rejected by the ACL. If so, run the undo peer peer-address sa-policy export command to delete the ACL configuration or change the ACL rule configuration.

    • If no export policies are configured on the MSDP peers, go to Step 5.

  5. Check that no import policies are configured on the MSDP peers.

    Run the display this command on the MSDP peers to view configurations in the MSDP view.

    • If import policies are configured on the MSDP peers, perform the following operations:
      • If the peer peer-address sa-policy import command is run and no parameters are specified, the MSDP peers do not receive messages from the multicast source. Run the undo peer peer-address sa-policy import command to delete the import policy configuration.

      • If the peer peer-address sa-policy import command is run and the acl advanced-acl-number parameter is specified, the MSDP peers receive only (S, G) entries permitted by the ACL. Check whether the ACL is configured on the MSDP peers and whether the (S, G) entries are rejected by the ACL. If so, run the undo peer peer-address sa-policy import command to delete the ACL configuration or change the ACL rule configuration.

    • If no import policies are configured on the MSDP peers, go to Step 6.

  6. Check whether an MSDP peer is the one closest to the multicast source.
    • If so, perform these troubleshooting operations on the upstream device.

    • If not, go to Step 7.

  7. Check that the MSDP peer closest to the multicast source is an RP.

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

    • If (S, G) entries do 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.

    • If the MSDP peer is an RP, go to Step 8.

  8. Check that import-source policies are not configured on the MSDP peer closest to the multicast source.

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

    Run the display this command on the MSDP peer closest to the multicast source to view configurations in the MSDP view.

    • If import-source policies are configured on the MSDP peer, perform the following operations:
      • If the import-source command is run and no parameters are specified, the MSDP peer does not advertise multicast source information. Run the undo import-source command to delete the import-source policy configuration.

      • If the import-source command is run and the acl acl-number parameter is specified, the MSDP peer advertises only (S, G) entries permitted by the ACL. Check whether the ACL is configured on the MSDP peer and whether the (S, G) entries are rejected by the ACL. If so, run the undo import-source command to delete the ACL configuration or change the ACL rule configuration.

    • If no import-source policies are configured on the MSDP peer, go to Step 9.

  9. If the fault persists after this troubleshooting procedures, contact technical support personnel.
Relevant Alarms and Logs

Relevant Alarms

None

Relevant Log

None

A Multicast Device Fails to Generate IGMP or MLD Entries

This section describes how to troubleshoot IGMP or MLD entry generation failures on a multicast device.

Common Causes

Common causes are as follows:

  • Multicast is not enabled on the device.

  • IGMP or MLD is not enabled on interfaces, or the IGMP or MLD version is incorrect.

  • Received EXCLUDE messages carry group addresses in the SSM group address range.

  • Multicast boundaries or group policies are configured on interfaces.

  • A maximum number of IGMP or MLD group memberships is configured on interfaces.

Troubleshooting Flowchart

Figure 4-75 shows the troubleshooting flowchart.

Figure 4-75 Flowchart for troubleshooting IGMP or MLD entry generation failures

Troubleshooting Procedure

Context

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Check that multicast is enabled on the device that directly connects to hosts.

    Run the display current-configuration command to view configurations of the device.

    • If multicast routing-enable is not displayed, multicast is not enabled. Run the multicast routing-enable command in the system view to enable multicast on the device and then perform IGMP or MLD configurations. For operation details, see the HUAWEI ME60 Configuration Guide - IP Multicast.

    • If multicast routing-enable is displayed, multicast is enabled. Go to Step 2.

  2. Check that the interface status is Up.

    Run the display interface interface-type interface-number command to check the configurations of the interface that directly connects to the user host network segment.

    • If interface-type interface-number current state: DOWN is displayed, the interface is physically Down. Check the networking to ensure that the interface is properly connected.

    • If Line protocol current state: DOWN is displayed, the protocol status of the interface is Down. Perform the following operations:
      • Check whether the interface is disabled.

        Run the display current-configuration interface interface-type interface-number command to check the current configurations of the interface. If shutdown is displayed for the interface, run the undo shutdown command in the interface view to enable the interface.

      • 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 no IP address is 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 } to reconfigure an IP address for the interface to ensure that the IP address is on the same network segment as those of the hosts.

    • If the interface status is Up, go to Step 3.

  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 directly connects to hosts.

    • If igmp enable or mld enable is displayed, neither IGMP nor MLD is enabled on the interface. Run the igmp enable command or the mld enable command in the interface view to enable IGMP or MLD.

    • If IGMP or MLD is enabled on the interface, go to Step 4.

  4. Check that the multicast group G of the EXCLUDE message is not in the SSM group address range.

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

    • If the command output shows that the multicast group G is in the address range permitted by the ACL, group G belongs to the SSM group address range. Ensure that IGMPv3 or MLDv2 is running between the host and the device interface.

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

    • If the command output shows that the multicast group G is in the address range denied by the ACL, group G belongs to the ASM group address range. Adjust the group address range specified in the ACL so group G is in the address range permitted by the ACL.

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

  5. Check that the range of groups that the hosts cannot join is not 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 directly connects to hosts.

    • If the group-policy field 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 based on the ACL configuration. 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 group G.

    • If the range of groups that the hosts can join is not limited on the interface, go to Step 6.

  6. Check that the number of entries and number of interfaces are below the upper limit defined in the product license.
    • If the number of entries and number of interfaces exceed the upper limit defined in the product license, re-plan network deployment.

    • If the fault persists after these troubleshooting steps are complete, go to Step 7.

  7. contact technical support personnel and provide the following information:

    • Results of this troubleshooting procedure
    • Configuration files, log files, and alarm files

Relevant Alarms and Logs

Relevant Alarms

None

Relevant Log

None

A User's Multicast Traffic Fails to Be Transmitted at the User Side

This section describes how to troubleshoot a multicast traffic transmission failure at the user side.

Common Causes

Common causes are as follows:

  • The upstream or downstream link is faulty.
  • IGMP or PIM is not configured.
  • The user has not gone online.
  • IGMP entries are not created for the user.
  • PIM entries are not created for the user.
  • Forwarding entries are not created for the user.
Troubleshooting Flowchart

The troubleshooting roadmap is as follows:
  • Check that the physical links are normal.
  • Check that configurations are correct.
  • Check that the user of which the multicast traffic is interrupted has gone online.
  • Check that the device has received IGMP Join messages from the user.
  • Check that IGMP entries are created for the user.
  • Check that PIM entries are created for the user.
  • Check that forwarding entries are created for the user.

Figure 4-76 shows the troubleshooting flowchart.

Figure 4-76 Flowchart for troubleshooting the multicast traffic transmission failure at the user side

Troubleshooting Procedure

Context

NOTE:

After the commands are configured to troubleshoot the faults, check the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to immediate validation mode.

  • In immediate validation mode, the configurations take effect after the commands are entered.
  • In two-phase validation mode, after the commands are configured, the commit command needs to be run to commit the configurations.

Save the results of each troubleshooting step so that if your troubleshooting attempts fail to correct the fault, you will have a record of your actions to present to Huawei.

Procedure

  1. Check that the upstream and downstream interfaces for the interrupted user-side multicast traffic are Up.

    Run the display this interface command in the views of the upstream and downstream interfaces to check the interface status.

    • If an interface is administratively Down, run the undo shutdown command for the interface.

    • If an interface is administratively Up but its physical status is Down, check the connection status of the physical link.

    • If both interfaces are administratively Up and their physical status is Up, go to Step 2.

  2. Check that configurations are correct.

    Run the display current-configuration interface interface-type interface-number command to check whether IGMP and PIM are enabled on the upstream and downstream interfaces.

    • If IGMP or PIM is not enabled on an interface, run the igmp enable or pim sm command accordingly.

    • If both IGMP and PIM have been enabled on the interfaces, go to Step 3.

  3. Check that the user of which the multicast traffic is interrupted has gone online.

    Run the display access-user user-id command to check whether the user has gone online.

    <HUAWEI> display access-user user-id 1280
    ---------------------------------------------------------------------------
    User access index              : 1280
    State                          : Used
    User name                      : root
    User IP address                : 10.138.78.61
    User access type               : Telnet
    User authentication type       : Administrator authentication
    Current authen method          : Local authentication
    Authen result                  : Success
    Current author method          : Local authorization
    Author result                  : Success
    Action flag                    : Idle
    Authen state                   : Success
    Author state                   : Success
    Current accounting method      : None Accounting
    Access start time              : 2011-03-02 01:57:22
    Accounting start time          : 2011-03-02 01:57:22
    Accounting state               : Start Accounting Idle
    User level                     : 3
    Current author cmd method      : local
    ---------------------------------------------------------------------------

    • If the preceding similar information is not displayed, the user has not gone online. Have the user go online.

    • If the preceding similar information is displayed, the user has gone online. Go to Step 4.

  4. Check that the device has received IGMP Join messages from the user.

    Run the display igmp statistics command to check IGMP Join message statistics of the user.

    <HUAWEI> display igmp statistics user-id 1280
    The data of user-id 1280 IGMP statistics:
     -----------------------------------------------------------
       Received successful V1 report packets number                : 0
       Received unsuccessful V1 report packets number              : 0
       Received successful V2 report packets number                : 96
       Received unsuccessful V2 report packets number              : 0
       Received V2 leave packets number                            : 0
       Received successful V3 report packets number                : 0
       Received unsuccessful V3 report packets number              : 0
       Sent query packets number                                   : 17
       Received invalid IGMP packets                               : 0

    • If the device does not receive IGMP Join messages from the user, have the user resend IGMP Join messages.

    • If the device has received IGMP Join messages from the user, go to Step 5.

  5. Check that IGMP entries are created for the user.

    Run the display igmp-snooping bas group-info command to check whether IGMP entries are created for the user.

    <HUAWEI> display igmp-snooping bas group-info GigabitEthernet 1/0/0 user-id 1280
    Group 225.0.0.1 information:
     Create time: 00:29:21
     Expire time: 00:02:07
     Group timer: Exist
     Retran count: 0
     Last member query: No
     Router filter mode: Exclude
     Compat mode: V2
     V1 host timer: Not exist
     V2 host timer: Not exist
     Source last member query: No
     Last member query timer: Not exist  

  6. Check that PIM entries are created for the user.

    Run the display pim routing-table command to check whether PIM entries are created for the user.

    <HUAWEI> display pim routing-table
    VPN-Instance: public net
     Total 0 (*, G) entry; 1 (S, G) entry
    
     (172.16.0.2, 227.0.0.1)
         RP: 2.2.2.2
         Protocol: pim-sm, Flag: SPT LOC ACT
         UpTime: 02:54:43
         Upstream interface: GigabitEthernet1/0/0
             Upstream neighbor: NULL
             RPF prime neighbor: NULL
         Downstream interface(s) information:
         Total number of downstreams: 1
             1: GigabitEthernet2/0/0
                 Protocol: pim-sm, UpTime: 02:54:43, Expires: 00:02:47

  7. Check that forwarding entries are created for the user.

    Run the display multicast forwarding-table command to check whether forwarding entries are created for the user. Then, go to Step 8.

  8. contact technical support personnel and provide the following information:
    • Results of this troubleshooting procedure

    • Configuration, log, and alarm files

Relevant Alarms and Logs

Relevant Alarms

None

Relevant Log

None

Translation
Download
Updated: 2019-06-11

Document ID: EDOC1000175918

Views: 4942

Downloads: 210

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next