＊
[SPAM] うざいスパマーをさらしあげ
新鮮広告：明日勝マガジン <tasuke2010@yahoo.co.jp> を一日に数十通送りつけるゲスなスパム野郎。
$ dig HYPER-MAIL.JP axfr @ns.miffy.to
hyper-mail.jp. 259200 IN SOA hyper-mail.jp. hostmaster.hyper-mail.jp.
2010051401 10800 3600 604800 300
hyper-mail.jp. 259200 IN NS ns.miffy.to.
hyper-mail.jp. 259200 IN NS ns11.akb-net.co.jp.
hyper-mail.jp. 259200 IN MX 10 admin.hyper-mail.jp.
hyper-mail.jp. 259200 IN A 210.224.161.121
mag.hyper-mail.jp. 259200 IN MX 10 mag.hyper-mail.jp.
mag.hyper-mail.jp. 259200 IN A 219.94.154.222
admin.hyper-mail.jp. 259200 IN A 210.224.161.121
mail.hyper-mail.jp. 259200 IN CNAME admin.hyper-mail.jp.
mag1.hyper-mail.jp. 259200 IN MX 10 mag1.hyper-mail.jp.
mag1.hyper-mail.jp. 259200 IN A 219.94.167.10
www.hyper-mail.jp. 259200 IN CNAME admin.hyper-mail.jp.
mm.hyper-mail.jp. 259200 IN MX 10 mm.hyper-mail.jp.
mm.hyper-mail.jp. 259200 IN A 202.181.98.237
mm2.hyper-mail.jp. 259200 IN MX 10 mm2.hyper-mail.jp.
mm2.hyper-mail.jp. 259200 IN A 210.188.218.86
mm3.hyper-mail.jp. 259200 IN MX 10 mm3.hyper-mail.jp.
mm3.hyper-mail.jp. 259200 IN A 219.94.179.89
users.hyper-mail.jp. 259200 IN CNAME admin.hyper-mail.jp.
ns.hyper-mail.jp. 259200 IN CNAME admin.hyper-mail.jp.
ftp.hyper-mail.jp. 259200 IN CNAME admin.hyper-mail.jp.
Domain Information: [ドメイン情報]
[Domain Name] HYPER-MAIL.JP
[登録者名] 株式会社エーケービーネットワーク
[Registrant] AKB NETWORK,Inc
[Name Server] ns.miffy.to
[Name Server] ns11.akb-net.co.jp
[Signing Key]
[登録年月日] 2005/03/26
[有効期限] 2012/03/31
Contact Information: [公開連絡窓口]
[名前] 株式会社エーケービーネットワーク
[Name] AKB NETWORK,Inc
[Email] webmaster@akb-net.co.jp
[Web Page]
[郵便番号] 876-0824
[住所] 大分県佐伯市
７２３２
フォンテーヌ２?２０３
[Postal Address] Saiki
7232
FONTAINE2-203
[電話番号] 0972-22-8382
[FAX番号] 0972-22-8382
219.94.179.89、210.188.218.86、202.181.98.237 はさくらインターネットにあるようだ。
210.188.218.86は大阪で応答なし、202.181.98.237は東京で応答なし。~
210.224.161.121 = admin.hyper-mail.jp で何か管理用かしら？
さらに調べていると、
http://mag.hyper-mail.jp/というのがあり、これもさくらインターネット上にあり、URLを開いてみると、メルマガ配信システム開発版とあるようだ。
つーわけで、この会社つぶれろ！うぜえ。
自由に登録出来る感じですね！
てことで、ばしばしいじってあげましょう！
AIR-AP1131AG-J-K9が8,800円で販売されているが、さらに追加でほしいなぁとおもった今日この頃。
日本で発売されているJ-K9については、J52しか対応しておらず、W52, W53 には対応していない。
また、先日日記に書いていたとおり、
[Network] Cisco Aironet アクセス ポイント 新 5GHz 帯対応へのマイグレーションは、
5/31で終了したとあります。
すなわち中古で買ったとしてもマイグレーションは出来ない状態にありますが、マイグレーションの出来ないJ52の無線機器を販売することは、
電波法違反になるのか、ならないのか。正直な疑問です。
Wikipediaをみると次のような記載。
PCカードなどのクライアント側はすべての周波数 (J52、W52、W53) に対応できることになっていたが、
無線ブロードバンドルータやアクセスポイントなど親機側では、新たにJ52対応の機器を販売することが
できなくなった。
うーん。ほしいけどどうなんだろう？？？
VIC TOKAI で見つけたIPv6サーバというのを作ってみた。
というのも、先日からPMTUDの問題だと思われる症状で接続出来ず、未だに接続出来ないので、
さらにいろいろと調べてみたところ、いろんなところにAAAAがついている。
大半の主要サービスにはついているようなので、一覧にしてみた。
けっこーいるねー。
さくさくとみてみるとがんばってるように感じる。
PMTUDの問題もがんばって直してくださいな。
おいらはどこから問い合わせたらいいかわからないので日記に書いておく。
なおしたらこっそりと教えてくださいね。
＊
[IPv6] www.ring.gr.jp のNICT管理のサーバがつながらない！
www.ring.gr.jp を閲覧しようとして、みれなかった。
調べてみると。。。
$ host www.ring.gr.jp
www.ring.gr.jp has address 133.243.3.209
www.ring.gr.jp has address 150.26.214.84
www.ring.gr.jp has address 160.26.2.178
www.ring.gr.jp has address 202.18.64.24
www.ring.gr.jp has address 210.159.71.23
www.ring.gr.jp has address 130.34.11.132
www.ring.gr.jp has address 133.23.250.240
www.ring.gr.jp has address 133.37.44.6
www.ring.gr.jp has IPv6 address 2001:2f8:2c:44::4
www.ring.gr.jp has IPv6 address 2001:df0:232:eed0::7
www.ring.gr.jp has IPv6 address 2001:240:3:2::1
www.ring.gr.jp mail is handled by 10 common.ring.gr.jp.
つながらなかったのは、2001:df0:232:eed0::7 のIPアドレスでNICT管理。
先日はSINETが年単位で放置されていたのが、今度はNICTが同じことをやらかしますか。。。
このご時世勘弁してくれよ。。。
AやAAAAをつけるならちゃんと運用する、サービスしないのだったら外せ。といいたい。ほんと。
＊
[Other] NIKON D300s + NIKKOR 50mm 1:1.4
＊
[TV] 踊る大捜査線 THE MOVIE~湾岸署史上最悪の3日間
＊
[TV] ルパン三世 DEAD OR ALIVE は懐かしいシーンがある！
こちらも懐かしい画面が登場。
ルパン三世 DEAD OR ALIVE は、1996年4月20日に公開された古い映画です。
この映画を見ていると、NIFTY SERVE を思い出します。
ゴールデンウィーク頃に放送されていて、懐かしいなとおもったので、紹介しますね。
最初に、シーンを説明しましょう。
不二子が潜入し、ナノマシンを停止させるプログラムの複製を行うシーンです。
コンピュータをみて、最新型だといい、MOを挿入していました。
画面はMacintoshを意識しているのでしょうか。
Magnet-Optical Disk
Compulsory Mount
強制マウントしています
不二子ちゃんはクラッカーでしたか。。
ルパンは過去に何度か同じようなシーンがある泥棒兼クラッカーなのは皆さん承知でしょう。
キーボードの入力ログを取得しようとしています。
ターミナルログって、当時はとったのでしょうか。
事前にキーロガーなどを仕込んでいれば別でしょうが、
不二子の様子を見る限り、この端末は初めてさわったような気配です。
OSには ZUFU OS Version 2.14とあります。
ZUFU とは、この映画の舞台がズフ王国にあることから、この名前が命名されたのでしょう。
Copyrightについては、KUBIKARI(首狩り)なんですね。
後ろからの画面になりますが、ATコマンドをたたいているのが見えます。
見にくいので、反転させてみましょう。
え？そこまで作り込むの？といいたいですが、
ATZ モデムの初期化
ATE コマンドエコー有無の設定
ATC え？ATDじゃないの？
という感じです。
ATコマンドの詳細については、
ATコマンド一覧を参考にしていただきたいのですが、つっこみどころは他にも。
ATDではなく、ATCでダイアルしており、ATCというのは、定義されていないように思えます。
電話番号は、電話番号ではない形式をとっているので、これは演出でしょう。
次に、
CONNECT 28800/REL5
FZUFU-ROAD 2
HOST NAME?
*C ZUFU
とあり、28.8kbpsでROAD 2でつながっています。NIFTYを意識するのであれば、ROAD 5ではないでしょうか。
ROAD 2とは、2400bpsまでで使用されていたAPだったはずです。
NIFTYというネタについては、次の写真で確認できますので、ここでは割愛します。
ターミナルログをみていて、なにやらログイン画面が出ています。
Historyでしょうか。
* C ZUFU
COM
Enter Connection-ID --->SVC
Enter User-ID --->H0B00423
Enter Password --->KUBIKARUZO
Connection-IDとは、NIFTYで使用されており、ここで文字コードの判別、接続するシステム(NIFTYなのか、CompuServeなのか)の選択になっていました。また、全角で入力した場合は、EUCか、SJIS、JIS、NECKなど判定されていた覚えがあります。半角の時はアカウントに対するデフォルトの設定値が設定されたような気がします。(
参考)
User-IDについては、アルファベット3桁、数字5桁。頭の3桁はアカウント種別になっており、シリアルが5桁のようなイメージになっています。
ここもNIFTYそっくりです。
Passwordについては、「首刈るぞ」なんですねｗ
改めて、ZUFU SYSTEMに不二子が入力しますが、今度はVersion 1.0.5 になっています。
最初の画面では、ZUFU OS Version 2.14 となっていたようですけど...
参考に、1996年4月10日のNIFTYにアクセスしていたときのログがありますので、参考に晒してみます。
比較用、懐かしむ形でどうぞご活用ください(笑)
★★★ ９６年０４月１０日 ★★★
NIFTY-Serve FENICS 3/4 (9600bps) 96/ 4/10 15:32:51 16:27:31 00:54:40 190 NTT
CONNECT 14400/V.42bis
FENICS-ROAD 4
HOST NAME?
*C NIF
COM
Enter Connection-ID --->SVC
Enter User-ID --->BYAXXXXX
Enter Password --->
ようこそNIFTY-Serveへ
Copyright (C) 1996
by NIFTY Corporation
All Rights Reserved
前回LOG OUT 96/04/08 21:10:58
−−メールが１通届いています（未読分１通）−−
＞GO MAIL
MAIL>H
【電子メール】
電子メールは、会員間での 1対 1の情報や手紙を交換する機能を提供するものです。
特定の会員へメールを送る場合、その人の利用者ＩＤを宛先として指定することに
よりメールを送ることができます。送付されたメールは NIFTY-Serveのホストコン
ピュータに保管され、好きな時に自分宛に送付されたメールを取出すことができま
す。もちろん特定個人宛のメールを他人に見られる心配はありません。
＊電子メールの機能
電子メールは、受信(REAd), 送信 (COMpose), 送受信簿表示(SDL, RVL), アドレス
ブック (ADDress), 転送 (FORward), 削除(DElete)の 6つが基本的な機能です。
その他の機能としてファイル転送処理を行うアップロード(UPLoad), ダウンロード
(DOWn), 電子メールの機能を使った FAX送信などの機能があります。電子メールを
誤って送ってしまった場合は、キャンセル(CANcel)機能で送信を取り消すことがで
きます。
まったくもって、そっくりですね。
当時、私はROAD 4を使用し、いっちょんちょんで接続していました。
そういう感じで楽しんでいただけたでしょうか:)
Amazonで購入する場合はこちらから
先ほど、踊る大捜査線でApache 1.1.3 のネタがあって、アーカイブはどこにあるんだろう、、と探してみたところ、見つけることが出来なかったが、Apache 1.3 の中に入っていることがわかった。。だけど、1.1.3はないようだ。。。
@yukihirokikuchi さん、情報ありがとう！
＊
[SPAM] 2011/09/24:09:43:57 FL1-119-242-26-184.tky.mesh.ad.jp [119.242.26.184]
次のログをみて、なにか、みて、気づかないだろうか。
[2011/09/07:15:38:52 +0900] FL1-119-242-26-184.tky.mesh.ad.jp RURI4e67117c3a180 1
"/diary/?200905c" "http://www.aaagroup.jp/"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP) AppleWebKit/525.19 (KHTML, like Gecko)
Version/3.1.2 Safari/525.21"
[2011/09/24:09:43:57 +0900] FL1-119-242-26-184.tky.mesh.ad.jp RURI4e7d27cde8071 1
"/diary/?200905c" "http://www.aaagroup.j/"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1"
Referer SPAMを行うにしてURIをタイポしている。
NPO法人アシスタント 代表 西崎道雄 03-3686-1295 はReferer SPAMを行うの集団ってことか。
うざいよ、悪質な取り立て、詐欺対処法とかやってるけど、おまえのところが悪質なんだよ！
ケケケと言い返してやろう。
Referer SPAMやるようなところ、依頼するような会社がまともであろうか。
さらに、調べてみると、
NPO法人データベース 団体名 特定非営利活動法人 アシスタントをみてみると、活動開始 2006年2月、事業内容に、（３）インターネット利用に伴うパソコンの操作・トラブルに関する相談事業 とあるが、おまえがトラブルの原因を起こしてどうなるんだ？といってやる。
ということで、今日の言いたい放題の晒し上げでした:)
Referer SPAMで困っているんですと、相談してみるとおもしろい？(笑)
時間あるときにやってみようｗ
とあるpublicなチャンネルでの会話で、汎用JPの卸値の価格が出ていたので、記録ｗ
2,250円らしい。
Value-Domain では、2,790円なので、1ドメインあたり、540円の利益。
お名前.com で、2,980円なので、1ドメインあたり、730円の利益。
ドメイン業は儲かりますねぇ。...
ただし、指定事業者になるなどの、お布施は必要ですが。
JPRSのサイトを探してみたら、2,250円という金額は出てこなかったが、ぐぐってみたところ、
いろいろなサイトで2,250円という金額が出ているので、WellKnownな価格であることは確かのようだ。
一時期Value-Domainではキャンペーンとして、2,250円で出していた時期もあったのね。
＊
[Network] hbstudy さくらのクラウド ネットワークの仮想化の設計と実装
hbstudy に参加してきました。
今回のお題は、さくらのクラウド。
特に、ネットワークの仮想化の設計および実装についての内容がテーマでした。
24時間以内のレポートはさすがに無理だぁ〜。てことで、2週明けにがっつりと書きましたよ〜。
Software Designが発売される前に、何とか出したかったのでがんばった！(笑）
「さくらのクラウド ネットワークの仮想化の設計と実装」 大久保氏
自己紹介を真面目にします。
2011/3/3 震災の少し前に、アマゾンが東京リージョンが開設すると言うことで、社長と石川さんがやってきて、「今からお前がクラウドの開発をやれ」と言うことでやり始まった。今で6ヶ月目ぐらいネットワークの設計と開発をやっている。
昨日、
publickeyさんより、
PR記事を書いていただきました。
さくらのクラウドでやるのは、IaaS、将来的にはSaaSもやるぞと社長は言っているが、今のところIaaSのみを考えている。
IaaSに求められることとして、CPUのコア数、メモリ、HDD、ネットワーク、割と自由に追加して、自分の作ったローカルのスイッチに接続できるといった、自由に構成が出来るのが特徴。仮想アプライアンス、データセンターにルータや、ファイアーウォール、ロードバランサーを持ち込んで、線を繋いでやっていた作業を全てクラウド上で出来るようにしましょうというのが、求められているのかなぁと思っている。
そういえば、1年ぐらい前に、社長がクラウドを作っていたが、それは、私的にはクラウドじゃない。VPSの延長じゃないかと思っていた。何故かというと、ネットワークの構成が出来ず、仮想マシンの構成の変更しか出来ない。ネットワークの構成変更が出来ず、私がプロジェクトに呼ばれたからには、色々と出来るようにしたい。
弊社では、ハウジングや専用サーバを借りて、大規模サイトを運用されるお客様が多い。1年ぐらい前から、VPSのサービスも提供させ頂いているが、色々なサービスは面倒くさいので、色々なサービスをクラウド上に乗せれるように、作りたい。
IaaS上での一般的なシステム構成。
ルータの下にファイアーウォール、ロードバランサーなどがあり、Webサーバを構築、バックエンドにDBサーバがある。
バックエンドを管理する為のVPN回線あるような構成が一般的ではないだろうか。
上記の構成を仮想化してみると、次のようになる。
IaaSネットワークの物理構成については、外部向けの回線をルータで受けてコアスイッチ2台で受けて、各ラックに設置しているエッジスイッチに分配していく。エッジスイッチは、サーバが増えれば増えるほど増設していく。
さくらでは、VLANを使って仮想マシン間を構成しており、仮想スイッチからルータまで、すべてVLANで構成されている。
VLANを使用した場合、VLAN-IDの制限があって、事前に4,000VLAN通しておく。
仮想サーバが立ち上がるたびに、仮想インターフェースをVLANに属させ、仮想ネットワークを組んでいる。
装置間の接続については、ユニークなVLANを割り当てていく。お客さんには見せていないので、気にする必要はないし、クラウドコントローラで自動で割り当てがされるようになっており、他のお客さんとかぶらないようになっている。
また、VM上のネットワークとして、仮想NICを仮想SWを経由して、VLANに接続される。
1ゾーンあたりの規模として、VLANは4,096個しか使えないので、VLANの単位でゾーンを分けている。
ホストサーバ500〜1000台ぐらい詰め込んで、VMは8000VMぐらいを想定し、1つのゾーンが構成される。
VMに仮想NICを平均2個搭載すると、MACアドレスは16,000程度必要となり、上記の用件を満たしたL2網を作らなければならない。
検討が必要な要素として、コアスイッチ、エッジスイッチ、仮想スイッチ、ルータなどをがある。
コアスイッチ、エッジスイッチの用件として、STPがよく使われるが、トラブルが多いので、さくらでは、STPは使わないということが目標であり、今ではスタック技術を積極的に使用し、冗長化している。エッジスイッチとの接続についてはLAG(リンクアグリゲーション)を使用し、スタックされた別々の装置に接続出来る構成になっている。その上に、すべてのVLANを通すような設定をしている。
コアスイッチの用件として、3,500以上のVLAN, 16,000以上MACアドレスの学習出来るスイッチを選定している。
エッジスイッチについても、L2網のため、コアスイッチとあまり変わらない。また、VLANおよびMACアドレス数が重要である。
スイッチの設定ミス等でループが起こらないようにその仮想マシンだけ切り離せるような構成にしている。
ベンダーのラボで検証したら、いろいろな問題が見つかった
ロジカルポート数の不足。カタログを見ると、4,000VLAN作れるが、すべてのポート、たとえば40ポートあるL2スイッチに、タグですべてのVLANを通す設定すると、設定できない箱が多い。ロジカルポートというのを内部で作るが、ポート数*VLAN数で4000*40で、16万ポートぐらいで、ほとんどの箱は12,000ぐらいか24,000ぐらいしかない。となると、3ポートとか6ポートしか割り当てが出来ない。選定の段階で問題がわかったので、選考から外すし、全ポートに全VLANを出すような箱を選定している。
次に、よくあるのがショートパケットでワイヤーレートが出ない。Etherフレームの最小フレーム地は64byteで、一番パケット数が多い。10Gでワイヤーレートを出すには、秒間14.88Mppsぐらいなので、結構装置にとっては、厳しい用件になってくる。
実際に満たす箱が無く、あきらめようとした。
なぜ64byteと決まっているかというと、CSMA/CD方式のコリジョン検出で、100m信号が伝わるためには、64byte出さないとコリジョンが検出出来ないため、決まった値である。128byteであれば、性能は半分でよかったのに。
考えた結果、「ワイヤーレートでなくてもいいんじゃね？」ということで、現実で問題のない範囲であればOKとしている。
具体的には80%、
DEL 98％しかでない
2%しか落とさないスイッチとか。
Q. 一番よかったスイッチのメーカーは？
A. えーっと....
Q. どこ採用されました？プレス出てました？
A. 出てましたね...
ブロケードさん？
VLANは、歯抜けで使えないVLANが存在する。
BrocadeはFCoEで予約されてある1002番のVLANが使えない。
C社さんのスイッチは、1002-1006や、show vlan internal usage は、routed interfaceに割り当てられた内部VLANなどがあり、上記のVLANは使用できないように、クラウドコントローラで割り当てないように設定をしている。
そのほか、VLAN 3583までしか扱えない箱があったり。。
※ ソース：
Brocade VDX AdminGuide: 3583. VLAN IDs 3584 through 4094 are internally-reserved VLAN IDs
実際に使えるVLAN数として、3500ぐらいが頭なのかなと考えている。
configが長くなる箱。非常に見にくく、メンテナンス性が悪い。
LACPがダウンする問題。ちゃんと冗長構成を取っているが、片方のコアスイッチを再起動すると、配下のエッジスイッチのLACPが一瞬ダウンして、通信が途絶えるということで、エッジスイッチのバグだったが、修正してもらって、現在は問題ない。
LACPは結構バグを踏むことがあり、Static LAGで組むのが一番良いが、KeepAliveしないので、リンクアップしたまま通信が止まるということがあり、通信ダウンがあるので、悩みどころ。今のところLACPを有効にして運用している。
MACアドレスのハッシュコリジョン問題。バグ^G^G仕様を踏むまで気づかなかった。
多くのL2スイッチのMACアドレスの学習にはハッシュテーブルを使用しており、ハッシュのコリジョンが発生する。コリジョンの発生してもよい許容量が決まっているが、それを超えると、MACアドレステーブルがすかすかなのに、学習出来ないMACアドレスが出始め、学習出来ないMACアドレスはUnknown Unicastとなり、Floodingする。さくらの場合は、Flooding系のフレームは帯域制限をかけるので、通信が遅くなるなどの悪影響が発生する可能性がある。
Q. MACアドレスをランダムにすると、MACアドレスが重複することが発生しないか？
A. コントローラですべて管理しているので、その問題は発生しないようにしている。
VLANでMACエントリを表皮する箱があり、某B社のスイッチでは、1VLAN設定すると内部で3エントリ消費してしまう。スペックでは、32,000VLANのスイッチで、4,000VLAN 作ると、12,000個のMACアドレスを消費してしまうので、残り20,000個しか使用出来ない。
先日OUI取得しました。
今では、9C-A3-BAでお客さんに割り当てている。
何で取得したかというと、Interクラウドで、他のクラウドでL2で接続しても、フレームをそのままとばしましょうという話があったり、事務所から、直接クラウドのサーバにL2-VPNで接続して直接接続してフレームをとばそうとすると、52-54-00などのKVMで使用しているMACアドレスを使用すると、お客さんが使っていると、ぶっちゃう可能性があるので、世界中でユニークなアドレスを取った方が良いよねということで、取得した。他のクラウドの相互接続性や物理ネットワークとの相互接続性などは問題無いようにしている。
Q. 本社の住所じゃないのはなぜですか？
A. (鷲北さん) 僕が、登録した。東京にいたもので、つい自分の名刺をみて、登録してしまった。
Q. 費用はどれぐらい発生するのですか？
A. 1750ドル、クレジットカードで決済出来る。
クレジットカードでOUIがとれる時代です。
仮想スイッチの用件として、次のものがあり、Open vSwitchを使用している。
スイッチでは、いろいろな用件があって、共有セグメントでは、他のお客のIPアドレスの乗っ取りが出来ないように、MAC Spoofing, ARP Spoofing, IP Spoofing の対策を行わないといけない。そのほか、仮想ポートで帯域制限が必要であり、帯域をお客さんに販売するので、契約帯域で絞るということをしている。
各ラックに設置されたエッジスイッチ(表裏)に、bondingで、冗長化するように、Open vSwitchに接続する。Open vSwitchまで、4,000VAN通して、クラウドコントローラでVMが起動するときに、tapインターフェースをOpen vSwitchに接続するときに、仮想ポートにvlanを割り当ている。仮想的なネットワークに接続することが出来る。
Q. ハイパーバイザーは？
A. KVMを使用している
Q. クラウドコントローラーは、自社開発ですか？
A. 自社開発で担当者1人で作ってる。
Q. VLANをたくさんつくるとき、どれぐらい起動に時間がかかりますか？
A. Open vSwitchはよくできていて、ポートをつなぐと、勝手に4000VLAN通る。
VLANをダイナミックに学習していて、来たフレームのVLANを自動で作り、
あらかじめVLANを作っておくという訳ではない。
4000 VLAN, 32,000 MAC通しても問題なく動くことを確認した。
Open vSwitchのMAC学習数に問題があり、デフォルトでは2,048となっていた為、ソースコードを書き換えた、32,768に書き換えて運用している。
フィルタでは、Open vSwitchはOpenFlowベースのアーキテクチャになっている。
ip, arpなどエントリを作ることでフィルタをする形になる。
src - mac , src - ip でフィルタしてる。
帯域制限。これも簡単で、tapインターフェースに指定すると、kbps単位で指定出来る。`
共有セグメントタイプであれば、100Mbps で指定している。
なお、現時点では、仮想スイッチからみて、ingress しか設定していない為、outgressは10G使えてしまう。
よくできているなとおもって、使っていたが、いくつか問題が発生した。
フローベースのアーキテクチャなので、DoSアタックなど、大量のフローが発生すると、転送性能が著しく低下する問題があった。
あるホストのVM当てにDoSアタックを食らうと、Open vSwitchを通過する他のお客さんにも影響が発生した。
カーネルモジュールのopenvswitch_modでパケットの転送処理を行っているが、いったんフローに展開するして、MAC Address, IP Address, Port番号など全部展開して、新規のフローについてはデーモンで動いているovs-vswitchdに問い合わせて、フローキャッシュとして、カーネルに保存します。なので、新しいフロー、DoSアタックみたいに、パケット単位でフローが発生すると、問い合わせが発生つづけ、ovs-vswitchdのCPUが上昇し続けた。フローキャッシュは、未使用エントリは5秒で、expireする。5秒で通信されないフローについては、いったんデーモンに問い合わせるようになる。5秒以下でも、1000エントリ超えると、削除するようになる。1,000エントリは、DoSアタックを食らうと一瞬であふれてしまう。
今の対策としては、1.2.1にバージョンアップした。
フローのセットアップ性能が50倍になり、だいぶ影響が受けにくくなった。
バージョンアップにより、ガベージコレクション開始の閾値を変更出来るようになった。
フローキャッシュの最大エントリも128kなので、12万ぐらいに設定して、多少あふれても問題ないように設定した。
根本的な解決策ではないくて、Open vSwitch自体、Flowベースなアーキテクチャなので、根本的な解決は難しそうな気がしている。今のところで、お客さんの仮想ポート毎にフロー数をモニタして、フロー数が異常になったら、帯域制限を行うよな監視システムを作ろうとしている。
あとは、Open vSwitchで仮想ポート毎に、フロー数の制限が出来るようになるとよいのかなと考えている。
ここからL3の話をします。
インターネットと接続する、エッジルータまでのネットワークで、エッジまではVLANを持ってきて、VLANインターフェースを作成し、エッジルータの2台にIPアドレスをを設定し、VRRP冗長している。
Q. LRなんですね？
A. すみません、SRにしたらやすくなったのでSRにしました。(資料の更新忘れ)
管理ドメインが違うバックボーンが増えてきて、どのようにして接続するか、というのが課題になっており、プライベートASを使用したBGP接続が一般的ではないかなとおもい、BGPで接続している。ちなみに、上のバックボーンは運用部が運用している。
これを設定した経路をそのまま上のバックボーンに経路を伝えると、クラウドコントローラーのバグなどにより、変な経路をバックボーンに流してしまったら、通信障害になるので、管理ドメインを分け、BGPで接続、プールするアドレスのみ受け入れるようにしている。
クラウドで使用するアドレス(/20など)をあらかじめプールしておき、ルータの設定で、配下のVLANに割り当てている。
ルータは、結構きびしいのがVRRPのインスタンスの数ではないかなともう。
お客さんが使うVLANにIPアドレスをたくさん割り当てていく。VRRPは、VRIDはそもそも256個しかない。全部のVLANに別のVRIDを使うことが出来ない。なので、別のVLANに同じVRIDを使える装置にしないといけないという制限がある。
実のところをいうと、ARPのエントリが厳しい結果が得られた。ルータの下に、8,000VMとか収容するので、ARPのエントリを作らないといけない。
実際にやってみると、VRRPのインスタンスを大量に作ると、VRRPの状態が変わり、フラックするという問題がある。試験したとき、2,000 VLANでIPアドレスを設定し、VRRPの設定を入れると、毎秒 2,000パケットのVRRP HELLOパケットが流れることとなり、バックアップ側が受け取れずに、勝手にマスターに昇格してしまう。
B社さんのルータで発生し、C社さんのルータでは発生する。
Q. VRRPを2000作ったとき、スレーブ側のCPU負荷はどうですか？
A. ラインカードのCPU負荷が張り付いていて、メインのCPUは大丈夫だった。
ルータ系のDDoSアタックを気にしている。
グローバルなIPアドレスがついていると、インターネット側から攻撃されてしまう。某B社さんのルータの23ポートに対して、ショートパケットをワイヤーレートで送りつけたら、CLIが固まる。
Q. マネージメントポートは使わないのか？
A. 上側のグローバルのデフォルトゲートウェイについては、隠せないので、どうしてもオープンになってしまうので、耐性だけ確認している。
配下に/16とかの大きな空間を作り、テスターで配下に12,800クライアントいるような環境で、トラフィックを流すとルータのCPU負荷が上昇し、CLIが操作出来なくなる。
Q. なぜ、ルータはB社さんを買ったのですか？なぜC社さんじゃない理由は？
A. ルータについては我々は何も申しわげていない。
B社とC社、両方買ってみた。よい方を正式サービスで使おうとした。
それで、大阪には、AゾーンとBゾーンがある。
全部試した。結局石狩では何を使うか、わかったかと思う。
てことで、Cisco採用されるそうです！！
VLAN ID数の克服として、ゾーンを分けることにしたが、お客様が、裏でゾーンをまたがる通信を接続したいという要望があることから、実装した。VLANを変換する装置となっている。
ゾーンをまたがる通信をするため、ゾーン#1 では、 VLAN100、ゾーン#2では、VLAN200だとしたときに、相互接続を行うため、VLANID変換装置で、VLAN同士をブリッジする。変換ルール数が250個ぐらいしかかけないという問題があり、別の機器の選定を行っている。~
将来的には、すべてのゾーンをまたがる任意のVLANをつなげる装置を準備したい。
だいぶ先の話として、専用サーバ、さくらのVPSといった他のサービスとの相互接続などで、こういうったVLAN変換装置が使えないか考えている。また、プライベートクラウドとお客さんの広域イーサなどといった専用線との接続も出来たら、と考えている。
今の仕組みでは、一カ所に集中しているので、網が広がっていたとき、そこをスケールするようなことを考えないといけない。
今考えているのは、PBB(Provider Backbone Bridge)や、KDDIさんがやっている、EoE(Ether over Ether)などがあり、一カ所だった装置を網として広げていこうと考えている。網の中では、24bitのユーザの識別しがあり、各サービスのL2網から持ってきたVLANを共通のIS-IDにマッピングを行い、相互接続が出来るようなアーキテクチャにしていきたい。
結局VLANで作ってきたが、スケーラビリティやVLAN IDのことを考えていくと、どうやって網を作っていくか考えないといけない。
発展途上であり、今使える技術としてはVLANしかなかった。
Ether over InfiniBandを検討しており、InfiniBandにEtherをそのまま載せてしまう。
内部資料をそのまま持ってきてしまったが、Ether over InfiniBand を石狩では検討し、実験しており、上がEthernetのネットワーク、ストレージのネットワークをInfiniBandで組んでいる。今までは、ホストサーバには、ストレージのネットワークとイーサのネットワークの両方を作らないといけなかったが、InfiniBandを使うと、ホストサーバとの接続をInfiniBandで束ねてしまいましょう。その上で、EtherとInifiniBandを束ねる装置をおいてしまう。この方式を、石狩で考えている。
IP over InfiniBand でその上でNFSで動いている。
そのほか、Ether over InfiniBandなどもある。
Etherのスイッチだと高いが、InfiniBandであれば、40Gのスイッチでもすごくやすく、帯域も簡単にアップできるし、網構成もシンプルに出来るという特徴がある。
完全トンネル方式。
Open vSwitch は某社さん、某N社さん。
NECさんですね！わかります。
GRETAPなど。。。
Q. MTUは？
A. 痛い問題ですね。基本的には、お客さんには、L2ネットワークだといっているので、IP-MTUは1500出さないといけないと考えている。バックボーンのMTUを大きくするか、トンネルするときに、フラグメントするか、どちらかで考えないといけないと思っている。~
今後Etherのスイッチを使わなくてもEtherのネットワークを作れる時代がくるのではないか！
クラウドでは、単純なネットワーク到達性では機能不足。従来のハードウェアアプライアンスに変わるものをクラウドで提供する。
仮想ルータ： Vyatta、IIJ SEIL/86(実験中)
仮想ファイアーウォール： pfSense、そのほか実装中
仮想ロードバランサ： 実装中
仮想ファイルサーバ：実装中
クラウドのネットワークはL2との戦いであり、研究レベルではL3到達性ではだめだと認識。
L2じゃないと、お客さんは使いにくい。L2でどのようにしてつなぐかが重要。
MACアドレス、VLAN数などの壁に当たるので、L2機器でがんばるのかトンネル方式でがんばるのか。
あとは、他のサービスとの相互接続性や、物理、既存のサービスの置き換えをしたい。
Diary for 4 day(s)
