В чем разница между полями «errors:», drop: »,« overruns: »и« frame: »в выходных пакетах ifconfig RX?

Может кто-нибудь, пожалуйста, уточните разницу между различными RX packetsполями в ifconfigвыводе?

Например, допустим, я бегу ifconfigи вижу следующее:

eth0      Link encap:Ethernet  HWaddr AA:BB:CC:DD:EE:FF  
          inet addr:1.1.1.1  Bcast:1.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:202723544 errors:0 dropped:4959 overruns:0 frame:37
          TX packets:158354057 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4261083782 (3.9 GiB)  TX bytes:1224803677 (1.1 GiB)
          Interrupt:83 Memory:f6bf0000-f6c00000 

В чем разница между errors: dropped: overrunsиframe:

Мое предположение на данный момент (основанное на некотором расплывчатом поиске) заключается в том, что это frame:конкретно относится к сбоям CRC, когда анализатор анализирует входящие кадры, и errors:это более общая категория. С другой стороны ... если бы это было так, я ожидал бы, что оба этих поля будут показывать числа.

Эта информация плохо документирована. Я скажу вам, что я понимаю из моего опыта.

• frame учитывает только выровненные кадры, это означает кадры с длиной, не делимой на 8. Из-за этой длины это недопустимый кадр, и он просто отбрасывается.

• Между тем errorsподсчитывает ошибки CRC, слишком короткие кадры и слишком длинные кадры.

• overruns считает, что в случае переполнения FIFO, вызванного скоростью, с которой буфер заполняется, а ядро ​​не может его очистить.

• Наконец, droppedподсчитывает такие вещи, как непреднамеренные теги VLAN или получение кадров IPv6, когда интерфейс не настроен для IPv6.

Я знаю, что это 1-летний вопрос, но он 1-й в Google, поэтому, возможно, я могу добавить к нему 5 центов.

Сначала я не знал об этом правиле мода 8 на поле кадра ... Это правило драйвера или правило ядра?

По моему небольшому опыту, эти числа довольно общие, и дополнительную информацию можно получить из ethtool(если драйвер поддерживает это) ex: это из watchкоманды.

Every 1s: ethtool -S eth1 | grep rx_ && echo  && ifconfig eth1                                                   1970-01-01 00:21:07

 rx_octets: 12635134290
 rx_frames: 8488675
 rx_broadcast_frames: 103
 rx_multicast_frames: 0
 rx_pause_frames: 0
 rx_64_byte_frames: 113
 rx_65_127_byte_frames: 47
 rx_128_255_byte_frames: 186340
 rx_256_511_byte_frames: 1
 rx_512_1023_byte_frames: 0
 rx_1024_1518_byte_frames: 8302174
 rx_greater_than_1518_byte_frames: 0
 rx_undersized_frames: 0
 rx_oversize_frames: 0
 rx_jabbers: 0
 rx_frame_check_sequence_errors: 0
 rx_length_field_frame_errors: 0
 rx_symbol_errors: 0
 rx_alignment_errors: 0
 rx_resource_errors: 283
 rx_overruns: 132
 rx_ip_header_checksum_errors: 0
 rx_tcp_checksum_errors: 0
 rx_udp_checksum_errors: 0

eth1      Link encap:Ethernet  HWaddr AA:BB:CC:DD:20:16  
          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::a8bb:ccff:fedd:2016/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:8488675 errors:415 dropped:4 overruns:132 frame:283
          TX packets:647464 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3892403548 (3.6 GiB)  TX bytes:62273943 (59.3 MiB)
          Interrupt:147 Base address:0xc000 

В зависимости от драйвера могут быть различные поля, ethtoolи ifconfigполя также могут указывать на слишком большие / слишком большие кадры.

Если ваш NIC & драйвер поддерживает это, вы можете (или должны) сделать ex:

ifdown eth1 && modprobe -r macb && modprobe macb && ifup eth1 && ethtool -offload  eth1  rx off  tx off && ethtool -K eth1 gso off && ethtool --show-offload eth1

чтобы получить больше информации (включите отображение информации в ethtool). Я использую драйвер MacB здесь ... так что проверьте ethtoolваш драйвер.

ethtool -i eth1

Это то, что обычно помогает мне понять, что происходит.

Иногда ошибок нет, но пакеты повреждены ... тогда это скорее физическая проблема или проблема с драйвером ... и иногда снифферы показывают, что все правильно, но возникает проблема после того, как он попадает в драйвер / ядро ​​(это вышеописанный случай фактически).

Еще некоторые могут быть получены из netstat -s, или если вы поместите это в скрипт (для небольших встроенных систем):

awk '(f==0) { i=1; while ( i<=NF) {n[i] = $i; i++ }; f=1; next} (f==1){ i=2; while ( i<=NF){ printf "%s = %d\n", n[i], $i; i++}; f=0}'  /proc/net/netstat

так как netstat -sможет быть недоступно.