Linuxのインタフェースのエラーカウンタの状態確認と原因　〜dropped, overrun, frame, carrier等～

Linuxのインタフェースのエラーカウンタ等の確認コマンド
IT/インフラエンジニアの地位とスキル向上のために

Linuxのインタフェースのエラーカウンタ等の確認コマンド

Linuxの通信速度が遅い、といった時など、ネットワークの問題に当たった場合は、Linuxのネットワークの状態、つまり、インタフェースの状態を確認しましょう。

特にエラーカウンタは重要です。昔は標準装備の ifconfig コマンドで見れましたが、CentOS7、RHEL7以降は ip コマンドが標準です。以下コマンドで見られます。

[root@localhost ~]# ip -s link show

上記コマンドの結果は以下のようになります。

RX = 受信パケット　、　TX = 送信パケット　です。

bytes

正常に受信/送信できたバイト数を意味します。

packets

正常に受信/送信できたパケット数を意味します。

errors

Ethernet の CRC エラーが検知され、処理できなかったパケット数を意味します。ケーブル接触不良やノイズ、受光が低レベルであることなどが原因として考えられます。

dropped

以下の4つのケースがあります。

Ethernetヘッダの"Type"に、サポートしていないプロトコルが入っていた場合
予期せぬVLANタグのフレームを受信した場合
IPv6を無効化したインタフェースでIPv6のパケットを受信した場合
softnet_stat の Backlog(積み残し処理) が許容量を超えたとき

1～3を総括すると、この dropped は「意図的に破棄した未サポートプロトコルパケットの数」を示しています。ただし例外が 4 です。これについては、そもそもこの dropped 等のインタフェースのカウンタを司る softnet_stat というプログラム自身において、処理しきれない程に大量のパケットが来たときに溢れたものも（プログラム構造上やむなく）dropped として取り扱うようです。

overrun

overrun は前述の dropped の "4" と同じ状況で起こりえます。ただし、こちらは rx-ring (ring-buffer) と呼ばれる、NIC の受信パケットを取り扱うメモリバッファ領域が確保できず破棄してしまったパケットを意味します。つまり、この overrun は「大量パケット（スパイク）を受信し、メモリバッファ不足により処理が行えず、やむなく破棄したパケットの数」を示しています。

つまり、通信量が多く、パケットの取りこぼしが起きるケースにおいては、softnet_stat のバックログ枯渇が先か、メモリバッファ枯渇が先かによって、どちらのカウンタがアップするかが決まります。これは環境依存です。

また、これらの値は（色々な通信を一手に引き受けるという意味で）LinuxよりもNW機器のほうが関心度が高いです。NW 機器でも Linux でも影響や考え方は同じです。詳しくはこちらに記載していますので「5. NW機器の転送能力のキャパシティを超えたとき」ぜひ参考にして下さい。

なお、Linux で rx-ring (ring-buffer) の確認、および変更するときは以下を実行します。

【確認】

[root@localhost ~]# ethtool -g ens33
Ring parameters for ens33:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256

【変更】

[root@localhost ~]# ethtool -G ens33 rx 1024

mcast

インタフェースにあるマルチキャストIPアドレスがアサインしており、かつ、その IP アドレス宛のマルチキャスト通信を正常に受信したパケットの数を示します。

なお、それ以外のマルチキャスト IP 宛パケットを受信した場合、どのカウンタにもカウントされません。

carrier

Ethernet フレームを送信しようと NIC にスタンバイさせたが、ケーブル接触不良やその他の理由で送信できなかったパケットの数を示しています。

その他の理由の一例として、(1000Base-T 以上ではあり得ませんが、) Duplex が half のインタフェースから送信しようとし、相手 (Duplex が full) のインタフェースから送信されたパケットを受信した場合、インタフェースは直ちに送信を止めるため、このエラーがカウントアップします。

この Duplex の full / half 問題は、Auto と固定を混在させたときによく発生します。