ただつらつらと日記が書かれていくようです。

タグ: ネットワーク

Vyattaでルータでも構築してみるか。って、まずNIC。

Vyattaというオープンソースなソフトウェアがある(開発はVyatta INC.)このVyattaはDebianベースのソフトで、x86サーバをCiscoのルータと競えるくらいのスペックに変えてしまう、ルータソフトウェア。で、Vyatta INC自体は、サポートが必要なら、サブクリプションを買ってくださいというRedHatに似たビジネスモデルで会社を営んでいる(あと、Vyattaをインストールしたアプライアンスも売ってるみたい)

で、ちょいとこのVyattaを使ってルータでも作ってみるかということでいろいろと企んでいたが、そもそもハードウェアどうするかというところで、適当なマシンを組み立てたけれど、前回の反省から、ちょっとNICには気を使おうと思っていた。

ま、こういうケアが意外と功を奏するものだ(…とはいえ、ややこしいことにはなっている)

まず、安NICを回避しようと思ったら、とりあえず、IntelのNICですよねーということ(発想は単純)で、最初は「Gigabit CT Desktop Adapter」(EXPI9301CT…で、コントローラはIntel 82574L)でも買おうかと思っていたんだけど、これが動作するためには「e1000e」ってドライバが必要…と。

だけど、今回のVyattaのターゲットバージョンは「Vyatta Community Edition 5」にしたけれど、このバージョンのベースになっているDebianのカーネルは2.6.26。で、この2.6.26には「e1000e」が入っていないとのこと。あー。

まぁ、ドライバを導入すりゃいいんだけど、どっちかというとルータにドライバ導入とかやりたくないような…。で、一方、従来のギガビットイーサネット用のe1000ドライバは持っているけれど、既にe1000で動作するIntel製NICが売ってなさげ(汗)ま、サーバ向けNICにあるけど、ちと高い。

というわけで、調べに調べてみた結果、HPのサーバ向けNICが古いコントローラを搭載しているらしいということに気がついた。それは、HPのNC110Tってやつ。しかも、9,000円。Intelのサーバ向けNICより、少し安い。これに使われているコントローラが「82572GI」って代物で、「Intel PRO/1000 PT Server Adapter」あたりに搭載されているコントローラ。このサーバ向けのPRO/1000PTは、Vyattaもサポートしているっぽいので、まぁ、なんとかなるだろうということで(汗)

HPのNC110T

新しく構築したマシンに挿してVyattaを起動してみたけれど、なんとなくうまく認識してるっぽい。後ほど、ちょっと使ってみる予定。

YAMAHAのRTXシリーズのip filterの謎な表記

YAMAHAのRTXシリーズのルータの設定を眺めていたら、謎の表記を発見(適当に伏字)

ip filter XX reject * * tcp,udp netbios_ns-netbios_ssn *

この表記の「netbios_ns-netbios_ssn」部分って、本来ならポート指定なんだけど…と思って調べてみたら、ヤマハのサイトに答えらしきものを発見。ニーモニックってのは馴染みが無いんだけど、エイリアスみたいなものなかなぁ…と。「RTシリーズで使えるニーモニック表」によると、

netbios_ns = 137

netbios_ssn = 139

…ということらしい。というわけで、上記の設定は以下のような設定と同じ意味ってことだろう。

ip filter XX reject * * tcp,udp 137-139 *

まぁ、このニーモニック表がアタマに入っている人なら、こういうのは何でもないことなのかもしれないけれども(汗)一応、メモ。

安いNICはもうイヤだ~makuosanとVIA Velocity編~

最近、KLabさんがオープンソースで公開している「makuosan」を使ってみようと、意気込んでセットアップしていたら、以下のようなエラーに直面して、どうにもならなくなっていた。

CentOSが動いている「とあるホスト」にインストールしてあるmakuosanが以下のようなエラーメッセージを/var/log/meassageに残して、接続先(まぁ、同期対象のホスト群)を見失ってしまうというエラーで、回復するためには放置しても無駄で(汗)makuosanを再起動するしかなささそうだけど、再起動してもしばらくするとエラーメッセージ(ちょっと加工してますが)を吐いて接続先を見失うという無限ループ(汗)

Sep 4 11:38:01 centos makuosan: root: mrecv_gc: pong timeout some.host.net

Sep 4 11:38:01 centos makuosan: root: [error] member_del_message: pong time out: XXX.XXX.XXX.XXX(some.host.net)

これが発生するのは、makuosanを起動、もしくは再起動してからだいたい5分後。起動直後の5分間はまともに接続先が見えているんだけどなぁ…と思いつつ、なんとなくiptablesの設定を疑って他のマシンの設定ファイルとdiffを取ってみたり、makuosanを再インストールしてみたり…と、とっても五里霧中な感じのトラブルシューティングが続いた。

で、うろうろしたあげくに、makuosanのソースの「makuosan.h」を見てみると、以下のような記載があった。

/*----- timeout -----*/
#define MAKUO_SEND_TIMEOUT  500    /* 再送間隔(ms)                                 */
#define MAKUO_SEND_RETRYCNT 120    /* 再送回数                                     */
#define MAKUO_PONG_TIMEOUT  300000 /* メンバから除外するまでの時間(ms)             */
#define MAKUO_PONG_INTERVAL 45000  /* PONG送信間隔(ms)                             */
#define MAKUO_RECV_GCWAIT   180000 /* 消し損ねたオブジェクトを開放する待ち時間(ms) */

エラーメッセージに「pong timeout」と書いてあったことと、MAKUO_PONG_TIMEOUTの時間から察するに、makuosan起動直後からPING/PONGによる接続先生存確認に失敗してる感じかなぁとぼんやり妄想してみたが、やっぱりよくわからない。しかも、調べてみると、「とあるホスト」からは、周囲にいる接続先が見えなくなるけれど、周囲にいる接続先から「とあるホスト」は見えたまま…とうアンシンメトリーな状態だったことがわかり、なんとも気持ち悪かった。

…で、もうなんとなくやることがなくなって、唐突ではあるけれど「NICが怪しい」と思い始めて調べてみた。この「とあるホスト」はコストをケチるために、オンボードのNICに加えて、玄人志向製の「GBE-PCI2」(…なんか安易な型番だな)を使っていて、使っているチップはVIAの「VT6122」とのこと。いわゆる、Velocityシリーズってやつ。

この「VIA Velocity」用のドライバは、私が知る限り、2種類あって、1つがCentOSに入ってる「via_velocity」で、もう1つがVIAのサイトからダウンロードできる「velocityget」。以前、とあるMLで「via_velocity」のデキがよろしくないようで、Sambaなどで性能劣化を起こすという投稿を見つけていたので、「とあるホスト」には、VIAのサイトから「velocityget」を落として組み込んであった。…はずだったが、先日、カーネルを更新した際に「velocityget」を再インストールするのを忘れてたらしく、lsmodしてみたら、いないはずの「via_velocity」がいらっしゃった!(modprobe.confでは「velocityget」を指定してあったけれど、肝心の「velocityget」が存在しないから、代わりに「via_velocity」が読み込まれて、何となく使えてたらしい)

目下、makuosanが接続先を見失う問題に対しては、特に打つ手もなかったので、期待を込めて「velocityget」をインストールしなおし、「via_velocity」を/etc/modprobe.d/blacklistに書き込んで、マシンを再起動してみた。

そして、makuosanが起動して5分後、やや緊張しながら/var/log/messageを覗くと…何にも出力されていない。「msync –member」をやってみても、makuosanは接続先を見失っていなかった!

…というわけで、起動して5分でmakuosanが接続先を見失うという問題は、makuosanとはまったく無関係な、安いNICと怪しげなドライバが原因だったという、なんともお粗末な結末…orz。

今度、マシンにNIC足すときは、なんとなくbroadcomとかIntelのNICにしようと決めた次第である。

*1:modprobe.confでは「velocityget」を指定してあったけれど、肝心の「velocityget」が存在しないから、代わりに「via_velocity」が読み込まれて、何となく使えてたらしい

なんかVyattaで検索されてるらしいので、Vyatta雑感

このBlogのアクセスが前日比700%超えとかになってて、ちょっと焦った。なんかやばいことを書いてしまったっけ…と思いつつ、調べてみると、Google先生に「Vyatta」について聞いた人がこのBlogに案内されているみたいだった。うーむ、なるほど、Vyattaですか。

Vyattaはご存知のとおり、ソフトウェアルーターと呼ばれているソフトウェア。Linux(Debianだったか)ベースなので、その辺で手に入れられるx86マシンをルーターに変えられる便利なもので、開発してるVyattaによれば、Ciscoの製品とも十分闘えるスペックをたたき出せるらしい(ま、私が関わっている環境では、そんなハイエンドな使い方はしないので、ふぅーんという感じ)

で、Vyattaが配布しているドキュメント(PDFなんだけど、ダウンロードするためにはメアドなどを登録しなきゃならず、、、面倒。しかも、ドキュメントもバージョンがこっそりあがったりして、新しいのを落とす度にいちいち登録しなきゃいけないのは…私だけ?)を眺めて、コンフィグを徒然なるままに書いてみての雑感を少々書き留めておこう(ネットワーク機器初心者の私の雑感なんて役に立たないに1票だけども)

前述のように、たいしたことをやんないでOKなネットワークを前提としているので、、、BGPがどーなんだ、OSPFはどーなんだという(…私がどこかで聞きかじったような…)キーワードを気にしてらっしゃるネットワークエンジニア諸兄にはまったくアレな内容でございます。すいません。はは(汗)

今回のコンフィグでは、とりあえずスタティックルーティングができればOKで、あとはファイヤーウォールでこっち側のNWに対する攻撃の防衛をやってみますかという感じ。というわけで、staticルーティングはドキュメントを見ながらがんばってくださいまし…という印象。ま、staticルーティングなんて、その辺のLinuxのディストリビューションでも実現できそうなことなんで、わざわざVyatta使うようなことでもないじゃんというのは確かにそうかも。

ただ、CUIで設定を行う場合、とりあえず設定を叩き込んで、commitするまでは、現状の設定との差分を表示してくれるので、割と設定しやすいような気がするし、ありえない設定(タイプミスとかのレベル)をしようとするとちゃんと叱ってくれるので、設定して再起動したら設定が間違ってて、あー(涙)みたいなこと(httpd.confでよくやるんですね、私は。近頃になって、syntax checkの技を覚えましたが)は少ないんじゃないかと思われ。

んで、今回の要件では、前述のとおり、Vyattaのファイヤーウォールでその下にぶら下がっているサーバ群に対するSSH Brute Forceとか防いじゃおうと思っていて、そういう意味ではファイヤーウォールの設定がキモかなぁと思っている。…でも、Linuxベースということは、ファイヤーウォールはiptablesそのものという印象。もし、Linuxのiptablesの設定をやったことがあれば、Vyattaのファイヤーウォールは造作なく設定できそうな気がする。ただ、「IN」とか「LOCAL」って概念はVyattaならではなのかなぁ、、、と思ったけれど、そこまでiptablesを極めてないので、誤解かも知れず。。。うーむ。あー。

一応、Vyatta Core 6.0を使ってドキュメントを眺め回しながら設定を書いてみたけれど、SSHへのアクセス頻度を制限することができたっぽい雰囲気。ま、割と簡単なんだろうなー。えーと、そういえば、Vyattaのドキュメントが英語なのは、生ぬるく笑ってわかったふりをするしかない世界かもしれず。

なんか雑な雑感だけど、とりあえず、雰囲気だけメモということで(笑)

そういえば、この前書いたエントリーで、Vyatta Core5では、e1000eが入ってなくてアレだなぁみたいなことを書いたけれど、Vyatta Core6を入れてみたら、普通にe1000eなドライバが入ってて、あー、何を心配してたんだかという感じ。とはいえ、HPの「NC110T」は、普通に認識されて使えてる感じなので、、、ま、いっか…と。

正しいL2スイッチの持ち方

今更こんなことを書いてどうする感ありまくりだけれど、まぁ、ネタ切れ気味ということで(笑)

さて、データセンターにL2スイッチ(いやまぁ、L3スイッチでもいいんだけど)を設置する際に、いきなりデータセンターに持ち込んでコンフィグするというのも手だし、それが手っ取り早いような気がするが、一方で、私としては、いきなりデータセンターに持ち込んでややこしいことになると面倒だなぁと思ったりするわけで、事前にちゃんと動く検証とかやっておきたいが、データセンターの爆音の中で作業はしたくない(変な話ではあるけれど、データセンターの中はサーバのファンの音しかしないので、脳がうまくノイズリダクションできれば、すごく静かな環境になるので…要はデータセンターで長時間作業すると疲れてきて眠くなってしまうのである)

もとい。そんなわけで、私の場合はL2スイッチとかサーバは、オフィスに納品してもらって、なんとかしてデータセンターに持ち込んで、ラックに設置するスタイルを採用することが多い。

これは、必然的にL2スイッチだとかサーバをデータセンターに持ち込む手段が必要になり、クルマを持っていない私は上司に迷惑をかけてしまう次第ではあるが、L2スイッチだけとなると相場が少し異なってくる。

要するに、L2スイッチを小脇に抱えてデータセンターに向かうという行為が可能になるのである。さすがに1Uサーバを抱えて電車に乗る気にはならないが、L2スイッチくらいの重さだと意外といけるのである。

f:id:y_fudi:20110131235926j:image

まぁ、電車でこんな感じで、小脇にL2スイッチを抱えてる姿を目撃されるのは、ちょっと気が引けるが、L2スイッチなんて持ち歩くもんでもないし、一時の恥に耐えれば…と思ってしまう。

で、いろいろと持ち替えて、L2スイッチの正しい持ち方(電車編)を研究しているウチに、データセンターの最寄り駅に着いてしまったので、結局、どう持つのが正しいのか結論は得られなかったが、写真の持ち方がかなり楽なことはなんとなくわかった(つり革が使えないので、意地でも座ろうと言う気になれる持ち方でもある)

あ、それがどうしたと言われると、とにかく困ってしまうわけだが…えーと、この前、L2スイッチを増設したって話題のつもりが見事に脱線したエントリーを書いてしまった次第である。