hogeとはワイルドカードのようなものです。日々起こった、さまざまなこと −すなわちワイルドカード− を取り上げて日記を書く、という意味で名付けたのかというとそうでもありません。適当に決めたらこんな理由が浮かんできました。
01/20/2003 夢
■ 夢
今日もわけの分からん夢を見ました。
どっかのアラブ系の砂漠で、俺は石油王になるべく油田を探してました。そこに地域の豪族みたいな人が、豚の頭が逃げ出した*1から探してるとか言って来て、俺はちょうどそれを少し前に捕まえてたので差し出しました。すると豪族の人は喜んで、少しばかりの土地をくれました。
俺はその土地を拠点として油田を探すつもりでしたが、その土地はジャングルみたいなところで、拠点どころかまずそこの開拓をしなければなりませんでした。
…ここで場面がすっとんで、なぜか俺はジャングルの中で毛布にくるまって、ハチの大群から身を守ってました。
終わり。
■ Gentoo
日本語表示のできるXMMSをxmms-jaとかいう名前でebuildにして、PROVIDE="xmms"としたら、emergeやebuildなど諸々のコマンドが使えなくなりました。パッケージの整合性が取れなくなったんかなぁ。emergeが使えないとどーしようもないので、1.4_rc2も出たことだしそっちに入れ換え。やっぱPROVIDE=xmmsってやるのは反則か。当然っちゃ当然だけど。PROVIDE=playerって感じにするのが良かったかも知れん。
それにしても、こんなことくらいでパッケージ管理が腐ってもらっちゃ困るんだが。
*1 この時点でもう何がなんだか。
01/20/2004 ふい
01/20/2007 むう
01/20/2009 ん
01/20/2013 ふむ
■ [Linux][メモ] CentOS 6 (2.6.32) の IPsec がなんかへんな件
gretap+ipsec, ipgre+ipsec, ipip+ipsec で同様に，スループットが異様に悪いという現象にぶち当たったので色々調査していたのだけれど，ワークアラウンドは見つけたのでメモっておく． はっきりとした原因はまだつかめていないけれど．
この「悪い」というのがどういうことかというと，後述する試験環境では素のトンネリングで 100M/s くらいなのだけれど，ipsec をかました瞬間に 15M/s 以下になり，その後どんどん遅くなっていき，500K/s くらいにまでなったりするというもの．とにかく安定しないのが特徴．
結論を先に書くと，ipsec をかますときはトンネルインタフェースに local を指定しておかないといけない． 指定しないと，動くけどスループットが異様に悪い．いっそ動かなければここまで悩むことはなかったのだけれど...
ちなみに 2.6.33 を乗せた Fedora Core 13 では local 指定がなくても遅くなったりはしない． CentOS 6 に無理矢理 FC13 の 2.6.33 をインストールして動かすと local 指定がなくても遅くならないので，2.6.32 に何かあると見てほぼ間違いない．
確認に使った環境は以下の通り． 家に物理マシンが 1 台しかないので全部 VM で． ipgre は構成的に ipip と同じなので割愛．
- gretap:
-
- ipip:
-
gretap の方はこんな感じで作る．対向側は remote/local を逆転させるだけなので割愛．
// racoon 設定．テスト用に軽そうなやつで
# vi /etc/racoon/racoon.conf
path pre_shared_key "/etc/racoon/psk.txt";
remote 10.0.0.102 {
exchange_mode main;
proposal {
encryption_algorithm aes;
hash_algorithm md5;
authentication_method pre_shared_key;
dh_group 2;
}
}
sainfo anonymous {
lifetime time 1 hour;
encryption_algorithm null_enc;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
// 事前共有鍵．何でもいい
# vi /etc/racoon/psk.txt
10.0.0.102 testpsk
// 色々モジュールロード
# modprobe aes
# modprobe esp4
# modprobe af_key
# modprobe ipcomp
# modprobe crypto_null
# modprobe xfrm4_mode_transport
// racoon スタート
# service racoon start
// ブリッジ作る
# brctl addbr br0
# ip link set br0 up
// veth 作ってブリッジに参加
# ip link add name veth0 type veth peer name veth1
# ip addr add 1.1.1.1/24 dev veth0
# ip link set veth0 mtu 1300
# ip link set veth0 up
# ip link set veth1 up
# brctl addif br0 veth1
// gretap 作ってブリッジに参加
# modprobe ip_gre
# ip link add name gre1 type gretap remote 10.0.0.102
# ip link set gre1 up
# brctl addif br0 gre1
// SPD 設定．ESP Transport Mode で
# cat <<'EOL' | setkey -c
flush;
spdflush;
spdadd 10.0.0.101 10.0.0.102 gre -P out ipsec esp/transport//require;
spdadd 10.0.0.102 10.0.0.101 gre -P in ipsec esp/transport//require;
EOL
ipip の場合は下記．racoon 周りは gretap と一緒なのでその辺は割愛．
// ipip 作る # modprobe ipip # ip tunnel add name tnl1 mode ipip remote 10.0.0.102 # ip addr add 1.1.1.1/24 peer 1.1.1.2 dev tnl1 # ip link set tnl1 mtu 1300 # ip link set tnl1 up // SPD 設定．ESP Transport Mode で # cat <<'EOL' | setkey -c flush; spdflush; spdadd 10.0.0.101 10.0.0.102 ipencap -P out ipsec esp/transport//require; spdadd 10.0.0.102 10.0.0.101 ipencap -P in ipsec esp/transport//require; EOL
上記はスループットが悪くなるもの． これを回避するには，トンネルインタフェース作成のところを以下のように変更する．
// gretap の場合 # ip link add name gre1 type gretap local 10.0.0.101 remote 10.0.0.102 // ipip の場合 # ip tunnel add name tnl1 mode ipip local 10.0.0.101 remote 10.0.0.102
最初に書いた通り，違いは local のあるなしのみ． この状態だと 35M/s くらいで安定した．
この local のあるなしが一体どんな差を生むのかということでコードを流し読みしてみたんだけれど，イマイチよく分からなかった... 結局のところはルーティングテーブルを引く時にソースアドレスを指定するか否かなんだけど，ルーティングテーブルのキャッシュのキーが変わるくらいにしか見えず，xfrm に渡るものは結局ソースアドレスを補完したものなので差がよくわからず． xfrm ってこのキャッシュを使って何かしたりするのかしら...
追記
CentOS 5 (2.6.18) でも試してみた (ipgre と ipip のみ) けどこの現象は起きなかった．やっぱ CentOS 6 (2.6.32) なんかおかしい．
□ kawahara [かまきりりゅうじw ]
□ atzm [われはかまきりなり 伸びんとす 伸びられるとき 伸びんとす 伸びられぬ日は 伸びぬなり ……違うか． ]