Droppedパケットの増加

はじめに

業務でとある試験中、Linuxサーバの受信側でDropカウンタが徐々に増加している問題があったので紹介します。

構成

各サーバ機器と繋がっているCiscoのCatalystスイッチと、作業用に持ち込んだPC接続用HUBが繋がっているだけの単純な構成です。

発生した事象

ip -s link showやifconfigコマンドの実行結果には、パケット破棄した数を示すdroppedの項目があり、通常は0となりますが、上記の構成で試験を行った際、HUBとPCを繋いだだけで特に何もしていないのにdroppedカウンタが徐々に上がっていく事象が発生しました。

コマンド実行例

# ip -s link show enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:28:aa:22 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    11104      130      0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    33559      111      0       0       0       0
                                ^^^^^^^
                                dropしたパケット数

パケットドロップの原因

droppedカウンタは以下のような場合に上昇します。

• 処理しきれない量のパケットを受け付けたとき
• LANコントローラの故障
• 未サポートのプロトコルを受け付けたとき
  • 予期せぬVLANタグのフレームを受け付けた
  • IPv6を無効化したインタフェースでIPv6のパケットを受け付けた
  • EthernetヘッダのTypeに、サポートしていないプロトコルが含まれていた

原因調査

今回の場合、HUBとPCをCatalystスイッチに繋いだだけで何も処理は行われていないので処理オーバーの可能性は無し。

また、複数あるLinuxサーバ全てでdroppedパケットが確認できたため、コントローラの故障も考えにくい。

ということで何か未サポートのプロトコルを受信しただろうと仮説を立て、サーバ側でtcpdumpを仕掛けてみるとRealtek Layer 2 Protocolsという妙なパケットが表示されました。

問題解決

作業用PCを繋ぐために使っていたHUBはバッファロー製のループ防止機能が付いたHUBとなり、HUBから定期的に流れるループ防止機能のヘルスチェックパケットがサポートしていないプロトコルとして検知されていたようです。

使用したHUBのループ防止機能は停止する機能が無かったため、別のループ防止機能が付いていないHUBに繋ぎ変えて対処しました。

おわりに

最近は数千円のHUBにもついているループ防止機能ですが、各社独自実装だったりするようなので、サポートしていないプロトコルとして検知される場合があるようです。

今回の事象であればサーバ側で破棄されても特に影響がなく、droppedカウンタが上昇するだけですが、気になる方はループ防止機能が動いている機器が無いか確認してみると良いと思います。