「cat / proc / net / dev」と「ip -s link」は異なる統計を表示します。どちらが嘘をついていますか？

8

/proc/net/deveth3には1753 drop秒あると言っています。ip -s link0を示しますdropped。なぜ違いがあるのですか？さまざまなデータはどこから取得されますか？どちらが正しいか？

余分なデータを取り除きました。

# 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
ソース

こっちも一緒。これは、ユーザ空間のプログラムでロールオーバー整数32ビットのように見えます（ifconfigここでは同じことを行います）しかしによるとbc、1258629839430%(2^32)ある204421702私はよく分からないので、（あなたは走っていない限り、それだと、244248462ないip後で〜40メガバイトを）

— DerfK

@DerfKはい、約40MBで問題ありません。ほんの数秒でしたが、それは忙しいサーバーです。

— ablackhat 2012年

11

Squeezeマシンでは、を信頼し/proc/net/devます。同じデータを確認するための、より簡単で信頼性の高い方法です。

ドロップ数の特定のケースでは、正確な問題を説明することはできませんが、他のSqueezeボックスでそれを観察できます。私が気にかけたら、私はそれをバグとしてDebianに報告します（そして誰かがそうし、ここに報告することを勧めます）。

どちらものtx_droppedフィールドから数値を取得しnet_device_statsます。では/proc/net/dev、線はdev_seq_printf_statsfrom によって生成されnet/core/dev.cます。

ip通常どおり、netlinkを経由します。より正確には、ネットワークデバイスの統計にはrtnetlinkを使用します。ユーザー空間に渡される構造rtnl_link_stats。

ネイティブ構造はunsigned longs、rtnetlinkusesを使用し__u32、多かれ少なかれ暗黙的な変換がで行われcopy_rtnl_link_statsます。

構造の最初から使用されている32ビットバージョン/proc/net/devrx_packets ipを簡単に見つけることができます。パケット数も同じです。

これらの2つの最初のフィールドの数値計算は次のとおりです。

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

の導入により状況は改善しましたIFLA_STATS64：

カーネル内（コミット10708f37ae729baba9b67bd134c3720709d4ae62から、v2.6.35以降のアップストリームで利用可能）
iproute2内（コミット8864ac9dc5bd5ce049280337deb21191673a02d0から、v2.6.33-36以降のアップストリームで利用可能）。

— ピエールキャリア
ソース

これはまさに私が探していたものです。

— ablackhat

-2

ほとんどのデバイスでは、/ proc / net / devはハードウェアカウンターから読み取られます。その他の統計は、デバイス構造のネットワークスタックから更新されます。

ドロップは、ハードウェアによって行われる可能性があるため、一致しない可能性が高くなります。パケットのMAC宛先がデバイスでもマルチキャストでもない場合、デバイスは無差別ではありません。ハードウェアが直接パケットをドロップするため、スタックはパケットが存在することを認識しません。

最後に、なぜそれらを同期しないのか、または常にハードウェア統計を使用しないのか疑問に思われるかもしれません。スタックが何らかの理由でパケットをドロップした場合、ハードウェアカウンターを更新できません。デバッグには、パケットがドロップされた場所を追跡するためにそれぞれを見つけることができると知っていると役立ちます。

お役に立てれば

— ブリーダー
ソース