RTL8111/8168B r8168 unknown chip version (2c800000)

以前にMalformed Packetとr8169 で書いた内容の検証がだいぶ進みました。
そもそもR8111/8168Bなんだから、はじめからr8169じゃなくてr8168で動かせよって話なのですが、elrepoのkmod-r8168をいれると、上がってこないというトラウマがあったため、別の路線をあたっていましたが、原点に変えることになりました。

きっかけはコレです。

unknown chip version (2c800000)
ACPI: PCI interrupt for device 0000:02:00.0 disabled
r8168: probe of 0000:02:00.0 failed with error -1

コンソールをよく見てみたら、unknow chipとおっしゃっています。
ethtoolでも次のように確認できます。

ethtool -d eth0
unknown RealTek chip

単純にr8168が古く、新しいリビジョンのチップを認識していないせいでした。
本家よりr8168-8.032.00をもってきてmake modulesしてr8168.koを入れ替えたら、すんなり認識しました。
ethtoolの結果も適正にみえます。

ethtool -d eth0
Offset  Values
--------        -----
000:     bc 5f f4 39 11 23 00 00 40 00 01 00 80 00 00 00
010:     00 00 00 00 00 00 00 00 24 0f 06 00 00 00 00 00
020:     00 40 8f 06 00 00 00 00 00 00 00 00 00 00 00 00
030:     00 00 00 00 00 00 00 0c 00 00 00 00 3f 80 00 00
040:     80 0f 90 2f 0e 87 02 00 00 00 00 00 00 00 00 00
050:     10 00 cf 9c 40 50 01 08 00 00 00 00 00 00 00 00
060:     40 11 00 80 01 ff ff 17 0c f7 00 00 93 00 c0 f0
070:     01 00 3f 00 dc f0 00 00 00 00 00 00 00 00 03 00
080:     24 fe 19 00 00 00 04 00 00 00 00 00 00 00 00 00
090:     92 4f 9e 0b f9 61 58 07 9a 60 6c 15 e9 88 23 49
0a0:     d1 98 bd a7 ae d6 72 52 f1 4f 80 07 bc 38 60 d3
0b0:     00 00 60 d3 ff ff ff ff ff ff ff ff 00 00 00 00
0c0:     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0d0:     60 00 00 32 00 00 00 00 00 00 f3 05 fb ff fe 00
0e0:     21 20 51 5f 00 80 8f 06 00 00 00 00 0c 00 00 00
0f0:     3f 00 40 00 00 00 00 00 ff 01 03 00 00 00 00 00

ひとつバージョンがうえのr8168-8.034.00もあったのですが、うまくコンパイルできなかったのでr8168-8.032.00を使いました。

これでなぞのフレーム化けと、パフォーマンスの低下がなくなってくれれば今夜はビールがうまいです。

LVSのDSR構成でリアルサーバにFIN_WAIT1 FIN_WAIT2が多発する問題

CentOSからUbuntu Serverへの入れ替えを進めてる最中だったりするのですが、グローバルに露出しているLVSをDSR構成でつかうと、リアルサーバにFIN_WAIT1と、FIN_WAIT2が大量に発生してしまいました。

LVSの方でtimeoutを通常より短めに設定していたため、ただちに大きな影響はありませんでしたが、これは放置できません。

ぐぐったらすぐでてきたのですが、iptablesがstateを評価すると、FINを落とすそうです。http://3.1415.jp/node/226

さて、そんな設定した覚えないのになーと思いつつ、ufwの存在をすっかり忘れているお馬鹿さんでした。
iptables -L でみると見たこともないような設定だらけ!
簡単にポリシーにそって設定できるufwですが、よかれとおもって入っているリッチ()な設定が悪さをしていました。

なのでとりあえず暫定的にstate部分を削除します。

探して、
iptables -L --line-number

チェインと番号を指定して消します。
iptables -D ufw-before-input 3

1リアルサーバあたり30000くらいあったActiveConnが、2500前後まで落ちました。スッキリ。

ufwを使わずに今まで通りに手で書いてrestoreするのか、ufwを使いこなすか悩むところです。

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

zfs poolにオンラインでストレージの追加

前回から随分たっていますが、2Tx4 RAIDZで構成したpoolにディスクを追加します。内容的には問題なければコマンド一行です。

zpool add -f data raidz /dev/sdf /dev/sdg /dev/sdh /dev/sdi

HDDが初期化されずに、MBRが残ったりしていると怒られるので-fをつけるようにと促されます。

以下のように2TのRAIDZ+RAIDZ構成のpoolができました。

# zpool status
  pool: data
 state: ONLINE
 scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    data        ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0
        sdd     ONLINE       0     0     0
        sde     ONLINE       0     0     0
      raidz1-1  ONLINE       0     0     0
        sdf     ONLINE       0     0     0
        sdg     ONLINE       0     0     0
        sdh     ONLINE       0     0     0
        sdi     ONLINE       0     0     0

errors: No known data errors

zpool list
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
data  14.5T  6.60T  7.90T    45%  1.00x  ONLINE  -