Como descobrir os motivos pelos quais a interface de rede está descartando pacotes?

Existe uma maneira no Linux de obter estatísticas sobre os vários motivos pelos quais os pacotes foram descartados?

Em todas as interfaces de rede (openSUSE 12.3) em vários servidores, ifconfige netstat -iestão relatando pacotes descartados na recepção. Quando eu faço a tcpdump, o número de pacotes descartados para de aumentar, o que significa que as filas de interfaces não estão cheias e descartam os dados. Portanto, deve haver outras razões pelas quais isso está acontecendo (por exemplo, pacotes multicast recebidos enquanto a interface não faz parte desse grupo multicast).

Onde posso encontrar essas informações? (/ proc? / sys? alguns logs?)

Exemplo de estatística (mesclagem da saída / sys / class / net / <dev> / statistics e ethtool):

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

Tente /sys/class/net/eth0/statistics/ (por exemplo eth0, para ), não é perfeito, mas divide erros por transmissão / recebimento e por portadora, janela, fifo, crc, quadro, comprimento (e mais alguns) tipos de erros.

As gotas não são iguais a "ignoradas", netstatmostram estatísticas no nível da interface, um pacote multicast ignorado por um nível superior (camada 3, a pilha de IP) não será exibido como uma gota (embora possa aparecer como "filtrado" em alguns Estatísticas da NIC). As estatísticas podem ser um pouco complicadas por vários recursos de transferência.

Você pode obter mais estatísticas se tiver 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
 [...]

Algumas estatísticas dependem do driver da NIC, assim como o significado exato. O acima é de uma Intel e1000. Tendo analisado um punhado de drivers, alguns coletam muito mais estatísticas do que outros (as estatísticas disponíveis para o ethtool tendem a ser mantidas em um arquivo fonte separado, por exemplo drivers/net/ethernet/intel/e1000/e1000_ethtool.c, se você precisar vasculhar).

ethtool -i eth0mostrará os detalhes do driver, a saída de lspci -vdeve ser mais detalhada, embora com um pouco de confusão também.

tg3.cFunção Update In , tg3_rx()existe apenas um lugar que parece provável com a tp->rx_dropped++, mas o código está repleto de gotos; portanto, existem várias outras causas além da óbvia, ou seja, qualquer coisa com goto drop_it ou goto drop_it_no_recycle. (Observe que o contador de recebimento é um dos poucos mantidos pelo driver, o restante é mantido pelo próprio dispositivo.)

A fonte do driver que tenho em mãos é 3.123. Meu melhor palpite é 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;
            }

Verifique a MTU, as possíveis causas são os jumbo-frames ou os quadros ethernet ligeiramente superdimensionados para permitir o encapsulamento. Não sei explicar por que tcpdumppode mudar o comportamento, não é conhecido por alterar a interface MTU. Observe também que você pode "ver" pacotes maiores que o MTU tcpdumpse o TSO / LRO estiver ativado ( explicação ).