主持NIC错误

\u00a0<\/p>

There are many reasons that can cause host NIC errors and troubleshooting this usually involves analysis to triangulate the issue to a certain part in the networking topology.<\/p>

• \t

  Link flapping (interface continually goes up and down)<\/p>\t<\/li>\t

• \t

  Cable disconnect\/connect<\/p>\t<\/li>\t

• \t

  Faulty external switch port<\/p>\t<\/li>\t

• \t

  Misconfiguration of the external switch port<\/p>\t<\/li>\t

• \t

  Faulty NIC port<\/p>\t<\/li>\t

• \t

  Faulty cable<\/p>\t<\/li>\t

• \t

  Faulty SFP+ module<\/p>\t<\/li><\/ul>

  The two big error counters that we are concerned are rx_crc_errors<\/strong> and rx_over_errors<\/strong> (and in conjunction, rx_missed_errors\/rx_fifo_errors).<\/p>

  Run the following command on your host depending on the hypervisor:<\/p>

  AHV:<\/p>

  ethtool -S <eth> | egrep \"rx_errors|rx_crc_errors|rx_missed_errors\"<\/code><\/pre>
  ESXi:<\/p>
  esxcli network nic stats get -n <vmnic> | egrep \"Total receive errors|Receive CRC errors|Receive missed errors\"<\/code><\/pre>
  Hyper-V:<\/p>
  Get-NetAdapterStatistics -Name Ethernet*<interface number> | fl *<\/code><\/pre>
  \u00a0<\/p>
  Rx_crc_error:<\/em><\/p>
  The sending host computes a cyclic redundancy check (CRC) of the entire Ethernet frame and puts this value in the FCS (frame check sequence) section of the Ethernet frame after the user payload. The intermediate switch then checks this computed value and the destination host to determine if the frame has been corrupted in transit.<\/p>
  rx_crc_errors are caused either by faults in layer 1, or issues with jumbo frames on the network. If that packet has an MTU over what is configured on the interface, it will cut off the packet at the designated MTU, causing the server to receive a malformed packet, which will throw a CRC error.<\/p>
  Faulty cables and\/or SFP+ modules are the most common cause of these errors. If the problem is regularly occurring on a particular interface, you should perform testing in a controlled fashion during a change window, to isolate the faulty component by swapping cables, modules, and switch ports as needed to isolate the issue.<\/p>
  Physical troubleshooting is a cumulative effort, as with CRC\u2019s, there is not an effective way to diagnose if the Host\u2019s NIC, the Cable, or the Switch port is the source of the bad data transmission.<\/p>
  Rx_over_errors:<\/em><\/p>
  They are caused when the hardware receive buffer on the physical NIC is full and some received packets have to be dropped at the physical NIC layer. In most cases, the values reported by this counter will equal rx_missed_errors and rx_fifo_errors. The packet drops can happen during high bursts of traffic.<\/p>
  \u00a0<\/p>
  These NIC errors can be triggered by a number of scenarios as indicated above and can usually be ignored. However, continuously increasing NIC errors usually point to a physical layer component that is failing. The Nutanix alert is triggered when the error rate is considered excessive. This alert should be investigated whenever it is raised and the source should be corrected.\u00a0<\/p>
  Pro-Tip : Engage your networking team to check Switch port statistics to captures errors on the switch side that these hosts are connected to.<\/p>
  For more information :<\/p>
  KB - 1381<\/a> - NCC Health Check: host_nic_error_check<\/p>","quoteUsername":"Nutonian","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
              
  
               
  像
               
  引用
               
  
               
  
                
  
                 
  
                  分享