Hello @gadisontag !
This counter shows you packets that were dropped by the switch due to outgoing buffer depletion. Typically it happens when there is a spike in the traffic destined to the device connected on this port. Like when you have 2 x 10G devices simultaneously communicating with 1 x 10G server. Or 40G device that sends data to 10G ESXi server. Normally TCP/IP handles such losses quite well, but it all depends on how much are those 1926544 packets in comparison to total outgoing traffic out of this port. Practically that counter is just a symptom of oversubscription of the Ten1/0/2. As for the impact, you need to test different scenarios with different load, nobody knows your network better than you.
The best solution will be to connect your server using multiple 10G links in order to share the load between NICs. It can be a BAGG (link aggregation) or just multiple standalone ports, it's up to you, but you need to provide more bandwidth to the server if you really feel the impact of the dropped traffic.
You can try two features of Comware switches in order to alleviate this problem:
1. Enable burst mode
system-view
burst-mode enable
The Burst feature enables the switch to automatically allocate cell and packet resources. It is well suited to the following scenarios:
• Traffic enters a switch from a high-speed interface and goes out of a low-speed interface.
• Traffic enters a switch from multiple same-rate interfaces and goes out of an interface with the same rate.
2. Use cut-through Layer 2 forwarding
system-view
cut-through enable
A cut-through forwarding-enabled switch forwards a frame after it receives the first 64 bytes of the frame. This feature reduces the transmission time of a frame within the switch, and enhances forwarding performance.
You can use them separately or together, but the real solution will be providing more bandwidth to the server.
Having cut-through enabled will disable CRC checking of frames on the switch itself, so if a frame will get corrupted, the switch won't care much about it and will just forward it "as is" to the destination. Practically you will see CRC error counter increasing on the end-device instead of a switch port if due to some reason you have corrupted frames in your network. When switches working in cut-through mode receive the frame, it will look up its first 6 bytes of the frame that following the preamble. Then the LAN switch will check the destination MAC address in its switching table, and determine the outgoing interface port, and forwards the frame to its destination. No CRC error-checking in cut-through switching process. But the overall latency is lower, in some cases it is much more important.
Burst mode has been already described, it's nothing more than more more suitable buffer resources allocation mechanism for bursty traffic.
I'd try the burst mode first and then the cut-through switching as a last resort option. But as I already mentioned the real solution is more bandwidth.
Hi @JUANTRON !
This command is not supported on this platform. And I doubt you really need it. It doesn't automagically resolve issues with dropped packets, it just MAY increase traffic forwarding performance. But if your switch struggles to handle traffic in your network maybe you need to revise its hardware configuration - increase number of fabric cards or replace them with more capable ones, change line cards with more newer ones that support higher speeds etc. etc. First, analyze the root cause of packet drops in your network and then plan the corrective measures. Putting arbitrary commands in the config found on forums (even if that forum is our wonderful community) was never a good idea.
In IRF mode:
burst-mode enable chassis chassis-number slot slot-number
You are welcome!
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00090286en_us
so on HP 10500 16p GbE SFP/8p GbE Cmbo SE Mod JC763A it should work. The rest are not supported by this feature