Exinda | Appliance is generating rx_errors

Summary

Overview

• rx_errors are a way for a NIC to show that it is running into some errors of varying kinds coming into a port
  • by contrast, tx_errors are errors upon transmitting information from a port
• rx_errors can indicate numerous things and, in some cases, can indicate that the Exinda is dropping traffic.
• However, in some cases, rx_errors alert are just an alert to notify an administrator that there might be something to pay attention to on ths NICs.

Cause

• This error means that because of a physical issue the packets received at any given interface do not comply with the ethernet standard and they must be discarded from a networking perspective.
• It is important to understand that the Exinda is behaving properly and as per the design, however it is simply letting the user know of a network anomaly.

Determine cause

1. After downloading the sysdump and decompressing it, there is a text file called "sysinfo.txt".
2. Open the file with wordpad or notepad++ and look for the section with the Outputs of '/usr/sbin/ethtool -S ethX' ; being X the specific number of the interface of interest.
3. Look up for the interface throwing the errors and there is a field called "rx_errors" which will point to the number of packets that have been counted as errors.
4. Surrounding this field look for another field that is also pointing at the exact same number, this field will be pointing to the actual reason.

• By running a quick search through the internet, there are several suggestions with regards to what these errors mean and what can be done to help.
• From a support perspective the most common causes are:

1. rx_long_length_errors: Some packets received are bigger than the MTU set in the interface under System-->Network-->NICs, which means the interface cannot possible deal with these packets.
   • This usually happens when there are Jumbo Frames in the network (9000 MTU) and the user forgot to apply the appropriate change in the bridge interfaces of the Exinda.
   • Also, if the user is using VLAN tags and the exinda is in the middle of a trunk link, the VLAN tag adds 4 additional bytes to the packet.
2. rx_crc_errors: This one is a little more complicated to diagnose.

• CRC stands for (Cyclic Redundancy Checking) and is a field with the packet that throws a hash value based on the structure of the packet in such a way that if the packet is corrupted along the cable, the hash value calculated with the new structure will be different.
• This points to a packet corruption and the network adapter must discard it.

3. rx_missed_errors: Errors that indicate that the queue on the port was full and so new incoming ports were dropped, because there were no room for them.

• These are analogous to 'buffer overrun' errors.

Resolution

1. For rx_long_length errors, modify the MTU of the Exinda interface so it can host bigger IP packets while the user verifies why the switch or router connected to it is sending these frames.
   • The right solution is to make sure the MTUs are the same between the Exinda's interface and the peer device.
   • Also, if the link is a trunk, it is recommended to increase the MTU of the Exinda interface by 4 bytes (From 1500 to 1504 for instance).
   • If the user is tagging double-vlans make sure to add 4 more bytes (1508 for instance).
   • The MTU being set up incorrectly could also lead to rx_crc_errors, due to the Exinda not being able to properly process the packet.
   • In these cases, the packets are not discarded, simply passed on.
2. For rx_crc_errors: try changing the patch cord, verify that the MTU/duplex/speed settings on the interface plugged into the Exinda are similar, look for potential electromagnetic waves that might corrupt the structure of the packet or look at the length of the cable (make sure its length is within standard specs).
3. For rx_missed_errors: Try checking the speed and duplex settings that are being negotiated between the Exinda and the device on the other side of that port.
   • If it's sending information too fast for the Exinda to handle (whether due to auto negotiation or whether the Exinda is processing packets due slowly for another reason), packets will be dropped.