Malformed Packetとr8169

新しく増設したサーバのパフォーマンスがイマイチなので、紆余曲折しながら調査した結果、00:00:00:00:00:00 -> 00:00:00:00:00:00 なイーサネットフレームが大量にブロードキャストされてることに気づきました。

wiresharkではMalformed Packetとして記録されています。

tcpdumpだとこんな感じです。

$ sudo /usr/sbin/tcpdump -n -i eth0 -s 0 -vvvv | grep -i null
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:09:41.834301 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
22:09:41.845293 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
22:09:42.058034 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
22:09:42.746298 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
22:09:42.855104 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46

lengthが短いのは自社サービスの特徴なので、普通に送信されたイーサネットフレームが00:00:00:00:00:00に化けて、スイッチが勘違いしてブロードキャストしてしまっているようです。
さらにPanasonicのスイッチがつながってるポートでは、Panasonicのスイッチ側でDiscardされていました。このDiscard数は増設したサーバのTCPセッション数に比例していました。

この化けたフレームをブロードキャストするのはProcurveなんですが、最近、部分的に導入したもので、以前はすべてPanaconic構成でした。Panasonicのスイッチだとポートでこの不正なフレームはDiscardされてしまうため、ミラーポートでは検出できません。スイッチポートのエラーカウンターを監視していたため、運よく気づくことができました。

その後調べてみたところ、別拠点でも同じようにNull Informationが少量ながら、検出できました。
Panasonicのスイッチではエラーとしてカウントされ、モヤモヤしてた実態が、Procurveのおかげでやっとわかったわけです。

MACアドレスが化けて判別ができないため、実際に環境を変えながらトラフィックを流したところ、犯人は蟹NICがついているサーバでした。しかもH67系では問題ないのですが、H77系マザーで、特定のプロダクトに投入すると、エラーフレームが大量発生するということです。
同時期に増設したサーバとも比較してみましたが、激しくエラーフレームを量産するのは2台だけという怪奇現象です。

r8168とr8169問題もあるので、ドライバについてもう少し煮詰める必要がありそうです。

※解決しました
http://takyaku.com/?p=118

コメントを残す

メールアドレスが公開されることはありません。


*