We have learned the principles and configuration methods of multicast. Today, let's continue to learn the troubleshooting of multicast, so that we can learn and understand it more deeply. Multicast protocols are classified into Layer 2 multicast and Layer 3 multicast.
Layer 2 multicast: A Layer 2 network is used between the multicast source and multicast group members. Layer 2 multicast is easy to configure and maintain, but is not flexible.
Layer 3 multicast: A Layer 3 network exists between the multicast source and multicast group members. Layer 3 multicast is generally applied to large-scale networks. This configuration is complex and difficult to maintain. However, the compatibility and scalability are strong.
Layer 2 multicast faults are usually caused by incorrect configurations or device faults.
Troubleshooting Roadmap
Sort out the fault path.
Checking the Multicast Configuration of the Device
Check whether packet loss occurs on the device interface.
Check whether loops exist on the device.
Check whether packet loss occurs in the cpu-defend.
Check whether packets are out of order.
Check whether IGMP packet exchange is normal.
Check whether the diagnosis logs contain multicast logs.
Troubleshooting Procedure
Sort out the fault path.
When troubleshooting multicast faults, we sort out the fault scope according to our principles and locate the fault scope. As shown in the following figure, there are multiple devices under multicast device A. The devices under multicast device A---B are normal, and the devices under the path from A---C are faulty. In this case, we can check the path from device A to device C instead of checking the path from device A to device B. In this way, we can reduce our workload.
2. Checking the Multicast Configuration of the Device
Incorrect device configuration is a common fault. Therefore, after the fault path is analyzed, check the device configuration first to check whether the fault occurs. The configuration of Layer 2 multicast is simple. Generally, you need to check whether the IGMP snooping function is enabled on the device. In addition, check whether other multicast-related configurations are enabled. For example, if the multicast-vlan enable function is enabled globally, you need to enable the same function in the VLAN view. Otherwise, multicast entries cannot be generated. The simplest method is to check whether the commands that must be configured exist according to the device manual.
3. Check whether packet loss occurs on the device interface.
If the device configuration is correct, check whether packet loss occurs on the interface of device A-----XXX. There are multiple methods to check packet loss.
1). Run the display interface gx/x/x command to check the interface status. This command is used to check whether the CRC count and pause frames on the interface are abnormal. If the receive and transmit signals or CRC of the interface are abnormal, replace the optical module or check whether the physical link is normal.
2). Run the display port-queue statistics interface g X/X/X command to check whether the number of discarded packets in queues on each interface is increasing. In the command output, check whether the value of discard increases. If a fault occurs, check the log to further identify the cause of packet loss.
4. Check whether a loop exists on the device.
After checking the interface count, check whether a loop exists on the device and whether the STP status is flapping. If a physical loop exists and the STP status flaps abnormally, Then, we need to check whether the cable connection of the device is incorrect.
5. Check whether packet loss occurs in the cpu-defend.
IGMP packets need to be sent to the CPU for processing. Therefore, you need to check whether the CPU-Defend packet loss occurs on the path. Run the display cpu-defend car protocol igmp statistics command to check whether the number of discarded IGMP packets increases. If the increase occurs, increase the CP-CAR threshold. However, this will consume CPU processing performance. Therefore, you are advised to modify this parameter with caution or based on the actual situation.
6. Check whether packets are out of order.
Packet disorder indicates that the packets received by a multicast group member device are disordered. Generally, a fault occurs when snowflakes occur. If packet disorder occurs on the device, packet loss cannot be found when checking packet loss on the device. The most common error occurs when the Eth-Trunk link is connected, and repeated packets are sent. If the fault occurs, use the packet capture tool to mirror the packets and check whether duplicate packets are sent. Alternatively, you can shut down one of the interfaces of the Eth-Trunk link to check whether the fault is rectified.
7. Check whether IGMP packet exchange is normal.
After checking the basic configurations and packet loss, you can check whether the IGMP packet status is normal. Check IGMP packets. You can run the debug command to check the packet exchange status between the multicast source and multicast group members.
U T D
U t m
debugging igmp-snooping report
debuggingigmp-snooping query
In the packet, check whether the request packet and the response packet can be received correctly.
8. Check whether the diagnosis logs contain multicast logs.
After the previous steps are checked, the fault cannot be rectified. In this case, you can only collect device diagnosis logs to determine whether the logs contain alarms or error information. For example, the downstream device fails to send IGMP packets.
