"Cat / proc / net / dev" e "ip -s link" mostram estatísticas diferentes. Qual deles está mentindo?

8

Percebo que /proc/net/devdiz eth3 tem 1753 drops. ip -s linkmostra 0 dropped. Por que existe uma diferença? De onde vêm os diferentes dados? Qual deles está correto?

Eu retirei os dados extras.

# uname -a
Linux example09 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012 x86_64 GNU/Linux

# lsb_release -a
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.4 (squeeze)
Release:        6.0.4
Codename:       squeeze

# cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  eth3:1258629839430 12545003042    0 1753    0     0          0  10594858 6666255952912 10026428444    0    0    0     0       0          0

# ip -s link
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:15:17:96:0b:61 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    244248462  3955476484 0       0       0       10595400
    TX: bytes  packets  errors  dropped carrier collsns
    683632524  1436809416 0       0       0       0

— ablackhat
fonte

O mesmo aqui. Parece um rollover inteiro de 32 bits nos programas de espaço de usuário ( ifconfigfaz a mesma coisa aqui), mas de acordo com bc, 1258629839430%(2^32)é 204421702não 244.248.462, então eu não tenho certeza de que é isso (a menos que você correu ip~ 40MB mais tarde)

— DerfK

@ DerfK Sim, cerca de 40 MB parece certo. Foram apenas alguns segundos, mas é um servidor ocupado.

— ablackhat

11

Em uma máquina Squeeze, confie /proc/net/dev. É uma maneira mais direta e confiável de ver os mesmos dados.

Para o caso específico da contagem reduzida, não consigo explicar o problema exato, mas posso observá-lo em outras caixas do Squeeze. Se eu me importasse, eu o reportaria como um bug ao Debian (e sugiro que alguém o faça e reporte aqui).

Ambos pegam o número do tx_droppedcampo de net_device_stats. In /proc/net/dev, a linha é gerada por dev_seq_printf_statsfrom net/core/dev.c.

ippassa, como de costume, pelo netlink e, mais precisamente, pelas estatísticas de dispositivos de rede, rtnetlink. A estrutura passada para o espaço do usuário rtnl_link_stats,.

A estrutura nativa usa unsigned longs, rtnetlinkuses __u32, uma conversão mais ou menos implícita é feita em copy_rtnl_link_stats.

É muito fácil entender que a versão de 32 bits está sendo usada desde o início da estrutura, rx_packets: enquanto /proc/net/devmostra 1258629839430, ipmostra 244248462, que corresponde aproximadamente aos últimos 32 bits (mais alguns bytes entre os comandos); mesma coisa com a contagem de pacotes.

Aqui está o número de processamento desses dois primeiros campos:

% echo '1258629839430 % (2^32)'|bc; echo 244248462
204421702
244248462
% echo '12545003042 % (2^32)'|bc; echo 3955476484 
3955068450
3955476484

As coisas melhoraram com a introdução de IFLA_STATS64:

no kernel (a partir do commit 10708f37ae729baba9b67bd134c3720709d4ae62, disponível upstream na v2.6.35 e posterior)
no iproute2 (a partir do commit 8864ac9dc5bd5ce049280337deb21191673a02d0, disponível upstream na v2.6.33-36 e posterior).

— Pierre Carrier
fonte

Ótimo, é exatamente isso que eu estava procurando.

— ablackhat

-2

Na maioria dos dispositivos, / proc / net / dev é lido nos contadores de hardware. Outras estatísticas são atualizadas da pilha de rede nas estruturas do dispositivo.

É mais provável que as gotas não correspondam, pois podem ser feitas pelo hardware: o destino do pacote mac não é nem dispositivo nem multicast, e o dispositivo não é promíscuo: o hardware descarta o pacote diretamente, a pilha nunca saberá que ele existia.

Finalmente, você pode estar se perguntando por que não sincronizá-los ou sempre usar estatísticas de hardware? Quando a pilha descarta um pacote por qualquer motivo, ele não pode atualizar o contador de hardware e, para depuração, é útil saber que você pode encontrar cada um para rastrear onde o pacote foi descartado.

Espero que isto ajude

— bleader
fonte