How to do when layer 3 multicast traffic fails to be sent to receivers?


Warning: foreach() argument must be of type array|object, string given in /www/wwwroot/wordpress/wp-content/themes/loobek/single.php on line 138

1. Checking Layer 3 Interface State and Multicast Protocol State

Check the state of the Layer 3 interface connected to the user network segment.
Run the display interface vlanif vlan-id command to check whether the Layer 3 VLANIF interface is in UP state.
 

<HUAWEI> display interface vlanif 3Vlanif3 current state : UPLine protocol current state : UPLast line protocol up time : 2012-08-03 03:54:16
Description:
Route Port,The Maximum Transmit Unit is 1500
Internet Address is 192.168.1.1/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 000b-0913-fc0b
Current system time: 2012-02-10 11:24:14
Last 300 seconds input rate 0 bits/sec, 0 packets/sec                           
Last 300 seconds output rate 0 bits/sec, 0 packets/sec                          
Input:  0 packets, 0 bytes                                                      
Output:  0 packets, 0 bytes
    Input bandwidth utilization  : --                                           
    Output bandwidth utilization : --

 
 
If the VLANIF interface is in DOWN state, physical interfaces in the corresponding VLAN may be Down. Restore the physical interfaces according to Interconnected Optical Ports Cannot Go Up or Interconnected Electrical Interfaces Cannot Go Up.
Check whether PIM and IGMP are enabled.
 
Run the display pim interface vlanif vlan-id command to check whether the PIM state on the Layer 3 VLANIF interface is up.
 

<HUAWEI> display pim interface vlanif 3
VPN-Instance: public net
 Interface      State   NbrCnt   HelloInt   DR-Pri     DR-Address
 Vlanif3       up      1        30         1          10.1.1.2

 
 
If the PIM state is down, enable PIM on this interface.
Run the display igmp interface vlanif vlan-id command to check whether the IGMP state on the Layer 3 VLANIF interface is up.
 

<HUAWEI> display igmp interface vlanif 3
Interface information of VPN-Instance: public net
 Vlanif3(192.168.1.2):
   IGMP is enabled
   Current IGMP version is 2
   IGMP state: up
   IGMP group policy: none
   IGMP limit: -
   Value of query interval for IGMP (negotiated): -
   Value of query interval for IGMP (configured): 60 s
   Value of other querier timeout for IGMP: 0 s
   Value of maximum query response time for IGMP: 10 s
   Querier for IGMP: 192.168.1.2 (this router)
  Total 1 IGMP Group reported

 
 
If the IGMP state is down, enable IGMP on this interface.
 

2. Checking Layer 3 Multicast Forwarding Entries

Run the display multicast forwarding-table command to check information about all Layer 3 multicast forwarding entries on the switch, including the amount of time an entry has been in Up state, amount of time left before timeout of the entry, as well as the inbound and outbound interfaces of the entry.
 

<HUAWEI> display multicast forwarding-table
Multicast Forwarding Table of VPN-Instance: public netTotal 1 entry, 1 matched
(10.10.10.2, 225.0.0.1)
     MID: 0, Flags: ACT
     Uptime: 00:08:32, Timeout in: 00:03:26
     Incoming interface: Vlanif10
     List of 1 outgoing interfaces:
       1:  Vlanif20
           Activetime: 00:23:15
     Matched 1775842131 packets(113653895502 bytes), Wrong If 0 packets
     Forwarded 1769618431 packets(1071392 bytes)

 
 
If the Layer 3 forwarding entry for the specific multicast group is displayed and the entry contains inbound and outbound interfaces, some users have joined this group. Check traffic statistics on the inbound interface to determine whether the multicast data stream for this group has reached the switch. If the switch has received the data stream, check whether the TTL value of the multicast packets is 1.
If the Layer 3 forwarding entry for the group exists but a large Wrong If counter value is displayed in the entry, the data stream the multicast source has failed the reverse path forwarding (RPF check). In this case, check whether the unicast route to the multicast source is reachable.
 
NOTE:
If VRRP is configured on the switch, there will be a small number of Wrong If packets, which do not affect functioning of the switch.
 
If the Layer 3 forwarding entry for the group exists but the outbound interface information is incorrect, the switch may have not received IGMP Report or PIM Join packets for this group. Check whether the switch is a designated router (DR) and whether it has received IGMP Report or PIM Join packets from downstream devices.
If no Layer 3 forwarding entry exists for the group, the multicast data stream for this group has not reached the switch. Check whether the switch has learned the rendezvous point (RP) address and whether the unicast routes to the RP and multicast source are reachable.

3.Checking the Unicast Routes from the Switch to the RP and Multicast Source

Run the display pim rp-info group-address command to check whether the switch has learned the correct RP address for the specific group.
 

<HUAWEI> display pim rp-info 238.0.0.2
VPN-Instance: public net
 Static RP Address is: 10.1.1.1
         Configured ACL: 2011
 RP mapping for this group is: 10.2.2.2 (local host)

 
If this group has no PIM RP information displayed, the switch does not learn the RP address on the local PIM-SM network. Check whether the RP configuration on the PIM-SM network is correct.
Run the display multicast rpf-info source-address command to check whether the switch has a reachable route to the multicast source.
 

<HUAWEI> display multicast rpf-info 192.168.0.1
VPN-Instance: public net
 RPF information about source: 192.168.0.1
     RPF interface: Vlanif100, RPF neighbor: 10.1.5.2
     Referenced route/mask: 192.168.0.0/24
     Referenced route type: unicast
     Route selection rule: preference-preferred
     Load splitting rule: disable

 
 
If no RPF information is available for the multicast source, the switch has no unicast route to the multicast route or PIM is not enabled on the Layer 3 interface facing the multicast source. Check whether the unicast routing and multicast configurations are complete.

4.Checking for Downstream Interfaces in PIM Routing Entries

Run the display pim routing-table group-address fsm command to check PIM (*, G) and (S, G) entries on the switch.
 

<HUAWEI> display pim routing-table 238.0.0.2 fsm
VPN-Instance: public net
 Total 220 (*, G) entries; 224 (S, G) entries
 Total matched 1 (*, G) entry; 1 (S, G) entry
 Abbreviations for FSM states and Timers:
     NI - no info, J - joined, NJ - not joined, P - pruned,
     NP - not pruned, PP - prune pending, W - winner, L - loser,
     F - forwarding, AP - ack pending, DR - designated router,
     NDR - non-designated router, RCVR - downstream receivers,
     PPT - prunepending timer, GRT - graft retry timer,
     OT - override timer, PLT - prune limit timer,
     ET - join expiry timer, JT - join timer,
     AT - assert timer, PT - prune timer
 (*, 238.0.0.2)
     RP: 1.58.126.249 (local)
     Protocol: pim-sm, Flag: WC
     UpTime: 08:17:06
     Upstream interface: Register
         Upstream neighbor: NULL
         RPF prime neighbor: NULL
         Join/Prune FSM: [J]
     Downstream interface(s) information:
     Total number of downstreams: 2
         1: Vlanif304
             Protocol: pim-sm, UpTime: 06:35:55, Expires: 00:03:27
             DR state: [NDR]
             Join/Prune FSM: [J]
             Assert FSM: [NI]
         2: Vlanif530
             Protocol: igmp, UpTime: 07:40:44, Expires: -
             DR state: [DR]
             Join/Prune FSM: [NI]
             Assert FSM: [NI]
     FSM information for non-downstream interfaces:
         1: Vlanif211
             Protocol: igmp
             DR state: [NDR]              
             Join/Prune FSM: [NI]
             Assert FSM: [NI]
 (1.58.127.150, 238.0.0.2)
     RP: 1.58.126.249 (local)
     Protocol: pim-sm, Flag: SPT 2MSDP LOC ACT
     UpTime: 07:49:08
     Upstream interface: Vlanif290
         Upstream neighbor: NULL
         RPF prime neighbor: NULL
         Join/Prune FSM: [SPT: J] [RPT: NP]
     Downstream interface(s) information:
     Total number of downstreams: 5
         1: Vlanif3000
             Protocol: pim-sm, UpTime: 02:08:48, Expires: 00:03:22
             DR state: [DR]
             Join/Prune FSM: [SPT: J] [RPT: NI]
             Assert FSM: [NI]
         2: Vlanif2300
             Protocol: pim-sm, UpTime: 03:07:44, Expires: 00:03:26
             DR state: [DR]
             Join/Prune FSM: [SPT: J] [RPT: NI]
             Assert FSM: [NI]
         3: Vlanif1000                    
             Protocol: pim-sm, UpTime: 03:07:50, Expires: 00:03:29
             DR state: [DR]
             Join/Prune FSM: [SPT: J] [RPT: NI]
             Assert FSM: [NI]
         4: Vlanif530
             Protocol: pim-sm, UpTime: 07:40:49, Expires: -
         5: Vlanif1100
             Protocol: pim-sm, UpTime: 03:07:42, Expires: 00:03:29
             DR state: [DR]
             Join/Prune FSM: [SPT: J] [RPT: NI]
             Assert FSM: [NI]
     FSM information for non-downstream interfaces:
         1: Vlanif304
             Protocol: pim-sm
             DR state: [NDR]
             Join/Prune FSM: [SPT: NI] [RPT: P, ET Expires: 00:03:22]
             Assert FSM: [NI] VPN-Instance: public net

 
If the PIM (*, G) and (S, G) entries for the specific group contain upstream and downstream interfaces, check whether PIM state on the downstream interfaces is DR or Assert Winner. If the PIM state on a downstream interface is NDR or Assert Loser, this downstream interface will not be delivered to the matching multicast forwarding entry. In a VRRP scenario, especially, you must configure igmp-snooping enable globally and in the VLAN corresponding to the VLANIF interface running the VRRP protocol. This configuration ensures normal switching of multicast data traffic in the VRRP group.
 

5.Checking IGMP and PIM Protocol Packet Counts

Run the display igmp control-message counters interface interface-type interface-number command to check IGMP packet statistics on the switch.
 

<HUAWEI> display igmp control-message counters interface vlanif 3
Interface message counter information of VPN-Instance: public net
 Vlanif3(192.168.2.1):
 Message Type                Sent        Valid       Invalid     Ignore         
 ------------------------------------------------------------------             
 General Query               1144        638186      0           0              
 Group Query                 0           0           0           0              
 Source Group Query          0           0           0           0              
 ------------------------------------------------------------------             
 IGMPV1V2          
 Report ASM                  0           0           0           0              
 Report SSM                  0           0           0           0              
 ------------------------------------------------------------------             
 LEAVE ASM                   0           0           0           0              
 LEAVE SSM                   0           0           0           0              
 ------------------------------------------------------------------             
 IGMPV3            
 ISIN Report                 0           0           0           0              
 ISEX Report                 0           0           0           0              
 TOIN Report                 0           0           0           0              
 TOEX Report                 0           0           0           0              
 ALLOW Report                0           0           0           0              
 BLOCK Report                0           0           0           0              
 Source Records Total        0           0           0           0              
 ------------------------------------------------------------------             
 Others                      -           -           0           0              
 ------------------------------------------------------------------

 
If the count of IGMP Report packets does not increase on the switch after user devices send IGMP Report packets, the possible causes are:
The switch does not receive the IGMP Report packets.
The received IGMP Report packets carry non-multicast destination MAC or IP addresses, which do not comply with the IGMP protocol.
The version of the received IGMP Report packets is later than that running on the switch.
Configure port mirroring to obtain packet information on the downstream interface to determine whether the switch can receive IGMP packets. If so, check whether the format of received IGMP packets complies with the IGMP protocol.
If the count of IGMP Query packets does not increase on the switch after the upstream querier sends IGMP Query packets, the possible causes are:
The switch does not receive the IGMP Query packets.
The received IGMP Query packets carry non-multicast destination MAC or IP addresses, which do not comply with the IGMP protocol.
The version of the received IGMP Query packets is later than that running on the switch.
Configure port mirroring to obtain packet information on the upstream interface to determine whether the switch can receive IGMP packets. If so, check whether the format of received IGMP packets complies with the IGMP protocol.
Run the display pim control-message counters interface interface-type interface-number command to check the counts of sent, received, and invalid PIM control packets on the switch.
When multicast forwarding fails on a PIM network, you can use this command to view counts of PIM protocol packets. The command output helps you locate faults.
 

<HUAWEI> display pim control-message counters interface Vlanif 3
VPN-Instance: public net
 PIM control-message counters for interface: Vlanif 3
 Message Type     Received         Sent             Invalid      Filtered
 Assert           0                0                0            0
 Graft            0                0                0            0          
 Graft-Ack        0                0                0            0          
 Hello            328              331              0            0
 Join-prune       2                0                0            0
 State-Refresh    0                0                0            0          
 BSR              0                0                0            0

 
 

6.Collecting Information and Seeking Technical Support

If the fault persists, collect related information and seek technical support.
Collecting Fault Information
Collect operation results of the preceding steps and record the results in a file.
Collect all diagnostic information and export the information to a file.
Run the display diagnostic-information file-name command in the user view to collect diagnostic information and save the information to a file.

<HUAWEI> display diagnostic-information dia-info.txt
Now saving the diagnostic information to the device
 100%
Info: The diagnostic information was saved to the device successfully.

 
 
When the diagnostic file is generated, you can export the file from the device using FTP, SFTP, or SCP.
 
NOTICE:
You can run the dir command in the user view to check whether the file is generated.
You can also run the display diagnostic-information command and save terminal logs in a diagnostic file on a disk.
If this command displays a long output, press Ctrl+C to abort this command.
This command displays diagnostic information, which helps locate faults but may affect system performance. For example, CPU usage may become high. Therefore, do not use this command when the system is running properly.
Running the display diagnostic-information command simultaneously on multiple terminals connected to the device is prohibited. This is because CPU usage of the device may obviously increase and the device performance may be degraded.
 
 
Collect the log and trap information on the device and export the information to files.
Run the save logfile all command in the user view to save the logs in the user log buffer area and diagnostic log buffer area to the user log file and diagnostic log file, respectively.

<HUAWEI> save logfile all
Info: Save logfile successfully.
Info: Save diagnostic logfile successfully.

 
When the diagnostic file is generated, you can export the file from the device using FTP, SFTP, or SCP.
NOTE:
You can also run the display logbuffer and display trapbuffer commands to view the log and trap information on the device, and save the information in diagnostic files on a disk.