Why are a large number of packets discarded on an inbound interface of an S series modular switch

46

S9300 series switches running V100R001 and V100R002 send protocol packets to the CPU for processing and discard the packets at the hardware layer. The number of these discarded protocol packets is counted on inbound interfaces, which does not comply with RFC 2863. For switches running V100R002, patches in V100R002SPH009 and later versions can be installed to fix this problem. According to RFC 2863 and industry norms, only packets discarded due to buffer overflows is counted as discarded packets.

Other related questions:
Why does an S series switch properly transmit small ping packets but discard large ping packets
A small MTU value on an interface of an S series switch may make the switch properly transmit small ping packets and discard large ping packets. You can run the ping -f command to measure the maximum packet length supported by the interface, and then check the MTU value on the interface. Note: The ping command uses ICMP packets. The packet size in the ping command output is the payload length of ICMP packets, excluding the length of the IP and ICMP packet headers. The length of the IP packet header is 20 bytes and that of the ICMP packet header is 8 bytes.

Why does an inbound traffic policy fail to filter traffic or limit the rate of inbound packets on an S series modular switch
For S series modular switches, a traffic policy fails to filter traffic or limit the rate of packets for users matching DHCP snooping binding tables. You can run the following commands to check whether static or dynamic binding entries exist: - Run thedisplay dhcp { snooping | static } user-bind { interface interface-type interface-number | ip-address ip-address | mac-address mac-address | vlan vlan-id } * [ verbose ] command to check static or dynamic DHCP snooping binding entries on an interface. - Run the display dhcp { snooping | static } user-bind all [ verbose ] command to check static or dynamic DHCP snooping binding entries on all interfaces.

Handling of many ARP request or replay packets received on S series switches
When S series switches receive a large number of ARP Request or Reply messages, the following problems may occur: -Users get offline, are frequently disconnected, experience slow Internet access and service interruption, or even cannot access the network. -The switches have high CPU usage or cannot be managed by the network management system (NMS), and their connected devices go offline. -Ping delay, packet loss, or failure occurs. You can perform the following steps to troubleshoot the preceding problems: Saving the results of each step is recommended. If your troubleshooting fails to correct the fault, you can provide the record of your actions to Huawei technical support personnel. 1. Run the display cpu-defend statistics packet-type { arp-request | arp-reply } all command in the user view to check whether the count of the dropped ARP Request or ARP Reply packets is increasing. -If the count is 0, the switches do not drop any ARP Request or Reply packets. Then go to step 6. If the count is not 0, the rate of ARP Request or Reply packets exceeds the CPCAR rate limit and excess ARP packets are discarded. Then go to step 2. 2. Run the display cpu-usage command in the user view to check the CPU usage of the MPU. - If the CPU usage is in the normal range, go to step 3. - If the CPU usage is higher than 70%, go to step 5. 3. Run the car command in the attack defense policy view to properly increase the CPCAP rate limit for ARP Request or ARP Reply packets. Note: Improper CPCAR settings will affect services on your network. It is recommended that you contact Huawei engineers before adjusting the CPCAR settings. The car command takes effect after you apply the attack defense policy. If the fault persists or the fault is removed but the CPU usage is still high, go to step 4. 4. Capture packet headers on the user-side interface and find the attacker according to the source addresses of ARP Request or Reply packets. If a lot of ARP Request or Reply packets are sent from a source MAC or IP address, the switches consider the source address as an attack source. Run the arp speed-limit source-ip [ ] maximum command in the system view to reduce the ARP packet rate limit based on the source IP address or run the arp speed-limit source-mac [ ] maximum command to configure ARP packet rate limit based on the source MAC address to adapt to actual network situations. By default, the function of ARP packet rate limit based on the source IP address is enabled, and the switches allow a maximum of 30 ARP packets with the same source IP address to pass through every second. After the rate of ARP packets reaches this limit, the switches discard subsequent ARP packets. The rate limit for ARP packets with the same source MAC address is 0, that is, the switches do not limit the rate of ARP packets based on the source MAC address. After the ARP packet rate limit based on the source IP address or MAC address is set to a smaller value (such as 5 bit/s), --If the fault persists, go to step 5. -- If the fault is rectified but the CPU usage is still high, configure a blacklist or a blackhole MAC address entry to discard ARP packets sent by the attack source. After that, if the CPU usage is still high, go to step 6. 5. Capture packet headers on the user-side interface and find the attacker according to the source addresses of ARP Request or Reply packets. If a lot of ARP Request or Reply packets are sent from a source address, the switches consider the source address as an attack source. You can configure a blacklist or a blackhole MAC address entry to discard ARP packets sent by the attack source. If the fault persists, go to step 6. 6. Collect the following information and contact Huawei technical support personnel: Results of the preceding troubleshooting procedure Configuration files, logs, and alarms of the switches

Reason for ping packet loss on S series switch
For S series modular switches: Ping packets sent from other devices to a switch are processed by the switch as fib-hit packets. The switch sends fib-hit packets to the CPU at the default CAR value to protect the CPU from being attacked by these packets. If the rate of ping packets sent to the CPU exceeds the CAR value, the switch discards the excess packets. To resolve the problem, set a larger CAR value for fib-hit packets.

Why ICMP packets used to ping a host cannot be discarded using a traffic policy on an S series modular switch
An S series modular switch sends ICMP packets to the CPU based on an ACL and discards ICMP packets based on an ACL in a traffic policy. The two ACLs are used for packet sending to the CPU and packet discarding respectively, and the ACL with a higher priority takes effect. The ACL for sending ICMP packets to the CPU has a higher priority. Therefore, ICMP packets cannot be discarded by configuring a traffic policy. To discard the ICMP packets, configure a blacklist. If the switch sends ICMP packets to the CPU through a route, you can configure a traffic policy to discard ICMP packets.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top