conntrackd に至る前置き

古い記事ですが、Slashdot 本家に Firewall Failover With pfsync And CARPという記事があった。良いなぁ。と linux 周りを眺めていたら ct_sync? という conntrackd 実装している方が、以前全てカーネルスペースで実装しようとしていた形跡を発見。ML にも入らず日々ダラダラ過ごしていたところ、conntrackd なるものを発見。ct_sync より勢いがありそうな感じで今後に期待....というのが今更ながらの前置き。そうそう CARP と conntrackd 使ってみたらしき ML への投稿があった気がする。

元気が無いのでまたまた貢献できないと思ふぅ。商用ファイアウォール製品と比較して、辛いな。と思う部分ですので、頑張って下さい。

conntrackd のオプション

目に余る逸脱ぶりなので、ちょっと戻る。-c の ``external cache'' という言葉に戸惑う。相変わらず内部、外部キャッシュの意味を理解していない.... conntrack-tools/src/main.c から

static const char usage_client_commands[] =
        "Client mode commands:\n"
        "  -c, commit external cache to conntrack table\n"

(プライマリ) 外部のキャッシュをコミット

        "  -f, flush internal and external cache\n"

(プライマリ、バックアップ) キャッシュのクリア

        "  -F, flush kernel conntrack table\n"

(バックアップ) カーネルの conntrack テーブルのクリア

        "  -i, display content of the internal cache\n"

内部キャッシュの表示

        "  -e, display the content of the external cache\n"

外部キャッシュの表示

        "  -k, kill conntrack daemon\n"

停止

        "  -s, dump statistics\n"

統計情報表示

        "  -R, resync with kernel conntrack table\n"

(プライマリ) カーネルの conntrack テーブルとの再同期

        "  -n, request resync with other node (only NACK mode)\n"

(ん? script_.*.sh にない) NACK モードにて他ノードとの再同期

        "  -x, dump cache in XML format (requires -i or -e)";

どーゆ経過か知らないけどキャッシュ内容の XML 出力

linux で Gigabit

New Reno では Gbit は辛いらしいと、どこかで目にした後うろうろしていたら

How to achieve Gigabit speeds with Linux

というドキュメントを見付けた。要約してみると

interrupt coalescence (ハードウェアで割り込み回数減らす)

# ethtool -c eth1
Coalesce parameters for eth1:
Cannot get device coalesce settings: Operation not supported

ガーン。他 -k や -g。ethtool(8) 参照

NAPI対応のドライバ

送信キュー長の変更

ifconfig だけど流行? であれば

ip link set eth1 txqueuelen 2000

あれ? デフォルト ip link ls eth0 で 1000 ある。

受信キュー長の変更

sysctl –w sys.net.core.netdev_max_backlog=2000

ちなみにデフォルトは

# cat /proc/sys/net/core/netdev_max_backlog
1000

TCP輻輳ウィンドウ 指数増加閾値上限なし

sysctl –w sys.net.ipv4.route.flush=1

こちらは /proc 下のパーミッションが

ls -l /proc/sys/net/ipv4/route/flush
--w------- 1 root root 0 2007-06-26 22:05 /proc/sys/net/ipv4/route/flush

SACK を無効に

競合がない...目一杯自分だけのテストなので

sysctl -w net.ipv4.tcp_sack=0

TCPバッファサイズの変更

上限

• net.core.rmem_max
• net.core.wmem_max
• net.ipv4.tcp_mem

デフォルト値

• net.ipv4.tcp_rmem
• net.ipv4.tcp_wmem

で試してないっと...

VMware workstation 6.0

Open Tech Press の記事 に VMWare6 すばらしい。らしき書かれていて眺めると

今回のWorkstation 6では、ユーザインタフェースなしでVMを実行できる。Workstationのウィンドウを閉じると、VMを電源オフにするかバックグラウンドで実行を続けるかの選択肢が表示される。これは、Webサーバなど、後で接続したいサービスをVMが実行している場合に便利だ。

と私にとって魅力的なものが。# もしかして Server でもできていた?

しかも x86_64 もあったので、早速 Upgrade して試してみたところ、まぁ上記通りライブラリ含めて 64bit になっていたし、ウィンド閉じようとすると daemon で稼働させるか聞いてくる。

2.6.22-rc をホストとした場合 sk_buff 周りの変更に vmnet が対応しておらず、ここから patch 持ってきてあてておく。cvut.cz にあった any-any-update が最近更新されていないのが少々恐い。

あとは個人的にネットワークは hostonl のインターフェースのみとして /usr/lib/vmware/net-services.sh いじって dhcp 止めるのとインターフェースのアップを vmware_bg_exec から vmware_exec へ。他 /etc/rc2.d/S19 番目。これやっておかないと dhcp の relay が動かんから。

# lguest が 32bit のみだから試すにあたって? 目的のための手段のための手段のための...

帯域増と転送速度

「10M から 100M に増速しました」増速? みたいな話のあと
「ファイル転送したけど転送時間あまり変わらないですね」
「いやぁ RTT が短くなった訳ではないですので、あまり期待しないで下さい」
....むーん、増速の速度って何よ。検索サイトに long fat pipe でお尋ねしましょう。

エンドユーザに実感してもらうには ftp がてっとり早いということで proftpd 入れて SO_SNDBUF SO_RCVBUF あたりを設定ファイルで...と調べたら tcpSendWindow tcpReceiveWindow とか...ではなく SocketOptions の rcvbuf sndbuf で指定するらしい。

カーネルコンパイルのオプション眺めると輻輳制御のアルゴリズム色々あるなぁ。10Gbit とかいう世界になると何が良いのでしょうか?

# /proc/sys/net/ipv4 以下や、ndd -set /dev/tcp も忘れずに。

tcpdump で wlan

tcpdump の filter expression でデータフレームだけ。こちら。バージョンまでひっくるめるならば

(wlan[0] & 0x0F) == 0x08

# radio header って、何見てわかったつもりになっていたっけ?
# 2.6.22 で 802.11 stack を新しい mac80211 とすると zd1211 が出てこん。