"Cat / proc / net / dev" e "ip -s link" mostrano statistiche diverse. Quale sta mentendo?

8

/proc/net/devNoto che dice che eth3 ha 1753 drops. ip -s linkmostra 0 dropped. Perché c'è una differenza? Da dove provengono i diversi dati? Quale è corretto?

Ho eliminato i dati extra.

# 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

Anch'io. Sembra un rollover a 32 bit intero nei programmi di spazio utente ( ifconfigfa la stessa cosa qui) ma secondo bc, non 1258629839430%(2^32)è 204421702244248462, quindi non sono sicuro che sia (a meno che tu non abbia eseguito ip~ 40 MB più tardi)

— DerfK

@DerfK Sì, circa 40 MB suona bene. Mancavano pochi secondi, ma è un server occupato.

— ablackhat

11

Su una macchina Squeeze, fidati /proc/net/dev. È un modo più semplice e affidabile di guardare gli stessi dati.

Per il caso particolare del conteggio abbandonato, non riesco a spiegare il problema esatto, ma posso osservarlo su altre caselle Squeeze. Se me ne importasse, lo segnalerei come un bug a Debian (e suggerirei a qualcuno di farlo e riportarlo qui).

Entrambi prendono il numero dal tx_droppedcampo di net_device_stats. In /proc/net/dev, la linea è generata da dev_seq_printf_statsda net/core/dev.c.

ippassa, come al solito, attraverso netlink e, più precisamente, per le statistiche sui dispositivi di rete, rtnetlink. La struttura passò a userspace, rtnl_link_stats.

La struttura nativa usa unsigned longs, rtnetlinkusa __u32, viene effettuata una conversione più o meno implicita copy_rtnl_link_stats.

È abbastanza facile rilevare che la versione a 32 bit viene utilizzata dall'inizio della struttura, rx_packets: mentre /proc/net/devmostra 1258629839430, ipmostra 244248462, che corrisponde approssimativamente agli ultimi 32 bit (più qualche byte in più tra i comandi); stessa cosa con il conteggio dei pacchetti.

Ecco il numero ridotto per quei 2 primi campi:

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

Le cose sono migliorate con l'introduzione di IFLA_STATS64:

nel kernel (da commit 10708f37ae729baba9b67bd134c3720709d4ae62, disponibile a monte in v2.6.35 e successive)
in iproute2 (da commit 8864ac9dc5bd5ce049280337deb21191673a02d0, disponibile a monte in v2.6.33-36 e versioni successive).

— Pierre Carrier
fonte

Fantastico, questo è esattamente quello che stavo cercando.

— ablackhat

-2

Sulla maggior parte dei dispositivi, / proc / net / dev viene letto dai contatori hardware. Altre statistiche vengono aggiornate dallo stack di rete nelle strutture del dispositivo.

Le gocce hanno maggiori probabilità di non corrispondere in quanto possono essere fatte dall'hardware: la destinazione del pacchetto mac non è né dispositivo né multicast e il dispositivo non è promiscuo: l'hardware rilascia direttamente il pacchetto, lo stack non saprà mai che esiste.

Infine, ti starai chiedendo perché non sincronizzarli o utilizzare sempre le statistiche hardware? Quando lo stack rilascia un pacchetto per qualsiasi motivo, non è in grado di aggiornare il contatore hardware e per il debug è utile sapere che è possibile trovare ciascuno per rintracciare dove è stato rilasciato il pacchetto.

Spero che sia di aiuto

— bleader
fonte