¿Cómo averiguar los motivos por los que la interfaz de red está descartando paquetes?

¿Hay alguna manera en Linux de obtener estadísticas sobre las diversas razones por las que se descartaron los paquetes?

En todas las interfaces de red (openSUSE 12.3) en varios servidores, ifconfigy netstat -iestán informando paquetes descartados en la recepción. Cuando hago un tcpdump, el número de paquetes descartados deja de aumentar, lo que significa que las colas de las interfaces no están llenas y descartan los datos. Por lo tanto, debe haber otras razones por las cuales esto está sucediendo (p. Ej., Paquetes de multidifusión recibidos, mientras que la interfaz no es parte de este grupo de multidifusión).

¿Dónde puedo encontrar esa información? (/ proc? / sys? algunos registros?)

Ejemplo de estadísticas (fusión de / sys / class / net / <dev> / stats and ethtool output):

alloc_rx_buff_failed: 0
collisions: 0
dropped_smbus: 0
multicast: 1644
rx_align_errors: 0
rx_broadcast: 23626
rx_bytes: 1897203
rx_compressed: 0
rx_crc_errors: 0
rx_csum_offload_errors: 0
rx_csum_offload_good: 0
rx_dropped: 4738
rx_errors: 0
rx_fifo_errors: 0
rx_flow_control_xoff: 0
rx_flow_control_xon: 0
rx_frame_errors: 0
rx_length_errors: 0
rx_long_byte_count: 1998731
rx_long_length_errors: 0
rx_missed_errors: 0
rx_multicast: 1644
rx_no_buffer_count: 0
rx_over_errors: 0
rx_packets: 25382
rx_short_length_errors: 0
rx_smbus: 0
tx_aborted_errors: 0
tx_abort_late_coll: 0
tx_broadcast: 7
tx_bytes: 11300
tx_carrier_errors: 0
tx_compressed: 0
tx_deferred_ok: 0
tx_dropped: 0
tx_errors: 0
tx_fifo_errors: 0
tx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_heartbeat_errors: 0
tx_multicast: 43
tx_multi_coll_ok: 0
tx_packets: 63
tx_restart_queue: 0
tx_single_coll_ok: 0
tx_smbus: 0
tx_tcp_seg_failed: 0
tx_tcp_seg_good: 0
tx_timeout_count: 0
tx_window_errors: 0

Intente /sys/class/net/eth0/statistics/ (es decir, para eth0), no es perfecto, pero desglosa los errores por tipo de error de transmisión / recepción y por operador, ventana, quince, crc, trama, longitud (y algunos más).

Las caídas no son lo mismo que "ignorado", netstatmostrar estadísticas de nivel de interfaz, un paquete de multidifusión ignorado por un nivel superior (capa 3, la pila IP) no se mostrará como una caída (aunque podría aparecer como "filtrado" en algunos NIC estadísticas). Las estadísticas pueden ser algo complicadas por varias características de descarga.

Puede obtener más estadísticas si tiene ethtool:

# ethtool -S eth0
 rx_packets: 60666755
 tx_packets: 2206194
 rx_bytes: 6630349870
 tx_bytes: 815877983
 rx_broadcast: 58230114
 tx_broadcast: 9307
 rx_multicast: 8406
 tx_multicast: 17
 rx_errors: 0
 tx_errors: 0
 tx_dropped: 0
 multicast: 8406
 collisions: 0
 rx_length_errors: 0
 rx_over_errors: 0
 rx_crc_errors: 0
 rx_frame_errors: 0
 rx_no_buffer_count: 0
 rx_missed_errors: 0
 tx_aborted_errors: 0
 tx_carrier_errors: 0
 tx_fifo_errors: 0
 tx_heartbeat_errors: 0
 [...]

Algunas estadísticas dependen del controlador NIC, al igual que el significado exacto. Lo anterior es de un Intel e1000. Habiendo examinado un puñado de controladores, algunos recopilan muchas más estadísticas que otros (las estadísticas disponibles para ethtool tienden a mantenerse en un archivo fuente separado, por ejemplo drivers/net/ethernet/intel/e1000/e1000_ethtool.c, si necesita hurgar).

ethtool -i eth0mostrará los detalles del controlador, la salida de lspci -vdebería ser más detallada, aunque con un poco de desorden también.

Actualización En la tg3.cfunción tg3_rx(), solo hay un lugar que parece probable con a tp->rx_dropped++, pero el código está lleno de gotos, por lo que hay varias otras causas que las obvias, es decir, cualquier cosa con goto drop_it o goto drop_it_no_recycle. (Tenga en cuenta que el contador de caída es uno de los pocos que mantiene el controlador, el resto lo mantiene el propio dispositivo).

La fuente del controlador que tengo a mano es 3.123. Mi mejor conjetura es este código:

           if (len > (tp->dev->mtu + ETH_HLEN) &&
                skb->protocol != htons(ETH_P_8021Q)) {
                    dev_kfree_skb(skb);
                    goto drop_it_no_recycle;
            }

Compruebe la MTU, las posibles causas son tramas gigantes o tramas de Ethernet ligeramente sobredimensionadas para permitir la encapsulación. No puedo explicar por qué tcpdumppodría cambiar el comportamiento, no se sabe cambiar la interfaz MTU. Tenga en cuenta también que puede "ver" paquetes más grandes que la MTU con tcpdumpsi TSO / LRO está habilitado ( explicación ).