¿Cuál es la diferencia entre los "errores:" "caído:" "overruns:" y "frame:" campos en la salida de paquetes ifconfig RX?

¿Alguien puede explicar la diferencia entre los diversos RX packetscampos en la ifconfigsalida?

Por ejemplo, digamos que corro ifconfigy veo lo siguiente:

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 

¿Cuál es la diferencia entre errors: dropped: overrunsyframe:

Mi conjetura en este punto (basado en algunas búsquedas vagas en Google) es que frame:se refiere específicamente a fallas de CRC cuando el nic analiza los marcos entrantes y esa errors:es una categoría genérica más amplia. Por otra parte ... si ese fuera el caso, esperaría que ambos campos muestren números.

Esa información está mal documentada. Te diré lo que entiendo por mi experiencia.

• frame solo cuenta cuadros desalineados, significa cuadros con una longitud no divisible por 8. Debido a que la longitud no es un cuadro válido y simplemente se descarta.

• Mientras tanto, errorscuenta los errores de CRC, los marcos demasiado cortos y los marcos demasiado largos.

• overruns cuenta los momentos en que hay desbordamientos FIFO, causados ​​por la velocidad a la que el búfer se llena y el núcleo no puede vaciarlo.

• Por último, droppedcuenta cosas como etiquetas VLAN no deseadas o recibir tramas IPv6 cuando la interfaz no está configurada para IPv6.

Sé que esta es una pregunta de 1 año, pero es la primera en Google, así que tal vez pueda agregarle 5 centavos.

Primero, no estaba al tanto de esta regla de mod 8 en el campo de marco ... ¿Es una regla de controlador o una regla de kernel?

En la poca experiencia que tengo, estos números son bastante genéricos y se puede obtener más información ethtool(si el controlador lo admite), por ejemplo: esto es del watchcomando.

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 

Dependiendo del controlador, habrá diferentes campos ethtooly los ifconfigcampos también pueden apuntar a cuadros de menor tamaño / gran tamaño.

Si su NIC y controlador lo admiten, puede (o debería) hacer, por ejemplo:

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

para obtener más información (permita que la información se muestre en ethtool). Estoy usando el controlador de MacB aquí ... así que verifique ethtoolsu controlador.

ethtool -i eth1

Esto es lo que me ayuda a entender, por lo general, lo que está sucediendo.

A veces no hay errores, pero los paquetes están dañados ... entonces es más un problema FÍSICO o de controlador ... y a veces los rastreadores muestran que todo está correcto pero hay un problema después de que llega al controlador / núcleo (este es el caso anterior Realmente).

Se puede obtener algo más de netstat -s, o si lo coloca en un script (para sistemas integrados pequeños):

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

ya que netstat -spodría no estar disponible.