Peering 相手やIXユーザMLにAS-PATH update送るのはやめようぜ、というお話。

こんにちは。酔っ払い系ツチノコです。

今回は、先月 IRS26  で話して来た内容です。ハイ、すんません。書くのすっかり忘れてました。

今回の話はよりネットワークよりの話です。特定層以外には全く通じない話の様な気もしますが、せっかくなので記事にしておきます。

すんごくすんごくはしょって大雑把にいうと、世の中のISPやアカデミックな組織、大規模な企業等のある程度の規模のネットワーク同士はBGP ( https://www.nic.ad.jp/ja/newsletter/No35/0800.html ) という仕組みを使って相互に接続しています。BGP では各ネットワークの塊を AS という番号を用いて識別していまして、例えば DMM.com であれば AS23620 というのが識別子になっています。

そして、AS間での相互接続のうち、対等に接続し、御互いに直接所属するネットワーク情報のみを交換する事を Peering といいます。(単にBGPに接続そのものを Peering という場合もありますが今回は詳細は省略…)

はい、ここまでは長い長い前置きです。

で、Peering している AS 同士では御互いに経路情報を交換するわけですが、本来意図していない経路情報が来た場合に拒否する為に、一定の経路フィルタをかけます。さて本題。

AS間の接続では少ない場合では数経路ですが、多い場合では数千〜数十万の経路を交換します。90年代後半からの歴史的経緯で日本では比較的細かい単位で厳密な経路情報をフィルタに書く習慣があります。「ひとつお客さんASがついたからみんなフィルタあけてね!」「ひとつPrefix(ネットワーク)が増えたからフィルタあけてね!」と言った具合です。

これがもう、大手ISPのお客さんが引っ越しした、ネットワークがひとつ加わった、なんてイベントは日常茶飯事なので、場合によっては毎日文字通り spam の様な数で送られてくるわけです。もう大変。

本来の目的は「異常な経路によりトラフィックが意図しない方向に引っ張られるのを防ぐ為に適切なフィルタをかけたい」ということなので、日本以外の国では「Private Address、Default route 等あきらかに異常な経路を拒否する」+「フルルートが流れてくると困るので一定の経路数までしか受け入れない」等の比較的運用が軽く、実用的なフィルタを適用する事が殆どです。

というわけで、日本でも歴史的経緯で細かなフィルタをかけてコミュニケーションコストをかけて自己満足するのはやめようぜ、というセッションだったのでした。

以上、長文の割に特定層にしかヒットしかしない記事、失礼しました。。。

JANOG39.5 Interim Meetingに参加しました

六本木オフィスはじめて♥のイベント

JANOG39.5 Interim Meetingに参加しました。
会場は、先日ご紹介した六本木の新オフィスです!
200人近い参加者がいらっしゃいました。

 

ストリーミング配信を担当しました

当日のストリーミング配信を担当しました。
新オフィスで開催する初めてのイベントでしたので、準備にドキドキ。
大きいスクリーンの一部が映らないトラブルはありましたが、配信については大きなトラブルもなく任務を完遂できました。
見てくださった皆さん、ありがとうございました!

DMM.comラボのエンジニアが登壇しました

今回のJANOG39.5 Interim Meetingでは2名のエンジニアが登壇しました。

StackStorm による統一インターフェイスと運用作業の一元化によるコスト削減の取り組み/大山 裕泰

登壇資料

テーマ:StackStormによる効率化の実現についての話

課題

・システムが増えることはあっても減ることはない→オペレーションが複雑化する→エントロピー増大
・オペレーションが特定のシステムに依存する問題

弊社の解決策

・StackStorm によるシステムの抽象化
・IFTTT x WorkFlow
・人がオペレーションに介在しないで済む
・個別のシステムの置き換えがユーザから見えない

StackStorm で発生する (ことが予想される) 課題

・StackStorm自体の管理・運用コストが発生する
・WorkFlowは書かないといけない
・足りないモジュールを何とかしないといけない
・オペレーションがStackStormに依存する

会場には実際にStackStormを使用しているエンジニアも多くいらっしゃり、盛り上がるセッションとなりました。

JANOG39 会場ネットワークの裏話/熊谷 暁

登壇資料

テーマ:JANOG39会場ネットワーク裏話

ツチノコNOC結成の目的

・会場ネットワーク構築ノウハウの蓄積
・社内・社外の非ネットワークエンジニアとの交流
・社内で会場ネットワークを準備することで費用の削減

今回のテーマ

・手堅くやろう!
・ある程度、誰にでも作れる会場ネットワークを提供するのが目標

ネットワーク構成

・VPNでデータセンタに接続し、サーバなどはデータセンタに配置
・データセンタから位置が遠いと、遅くなることも

Wi-Fiチームについて

・現場配線チーム
・現地で距離の測定、APをどこに設置するか決める
8の字巻について

今後の野望

・オンプレのサーバをパブリッククラウド上に置きたい
・CONBUで、さくらのクラウドを利用した会場ネットワークを提供しました

関連記事:イベント会場ネットワークにさくらのクラウドを活用してみた 第1回 – インターネット接続編

個人的に面白かったセッション

博多駅前の陥没事故で何が起きたか

博多駅前で陥没事故が起きた際、突然の大量アラート発生から復旧までのお話。
想定外は身近で起き、これをやっておけば十分だということはない。
先入観は判断を鈍らせ、分かっていてもいざという時焦ってしまう。
という言葉が、心に残りました。
人的被害が一切発生しなかったのも、タイミングがよかったのだなと。

AWS の IAM 秘密鍵を GitHub に push したあと 1 時間でされたこと

IAMコードの入ったコードをGitHubに上げてはいけません!
579万7028円の請求が!!
多要素認証しているから自分が乗っ取りにあうことはない、自分に非はないと考えるのはよくない。
パニックになるとフォーカスが狭くなる、一人では解決できなかったかもしれない。
婚約者さんマジ天使!(イイハナシダナー
# 婚約者さんが「これでは?」と送ってくれたQiita

最後に

イベント後の懇親会も盛り上がり、大盛況でした。
恵比寿のイベントスペースに比べ収容可能な人数も増え、イベントスペースの使い方も広がりそうです!
何かの際には、ぜひ足を運んでください。

六本木オフィスに引っ越してきました!

インフラ部隊も大手町オフィスから六本木に引っ越してきました。
#残っているチームもいます♪

移動してまだ数日ですが、六本木オフィスは新しくて気持ちがわくわくします。
駅直結のビルなので、通勤時に雨に濡れることがなくなりましたし、
窓が大きく光が入るのでとても過ごしやすいです。

窓の外には、東京タワーやレインボーブリッジという景色が広がっています。
大手町ではすぐそこに見えていたスカイツリーは少し遠くなってしまいました。

 

#窓ガラスが緑色なので青みがかった写真ですみません。

入り口にたくさんのお花が飾られているのですが、そのなかに気になるお花がありました。

お花の中に手作りのチーノ君がいます!!

可愛らしいお花とチーノ君に胸キュンです。
席の近くにお花を移動させてもらいました。うれしい。

作業スペースは仕切りがなくフラットな作りになっています。

机の大きさは大手町オフィスよりも若干大きくなりました。
机の仕様上、4Kモニタにアームが付けられなくなってしまったのは、残念。

フロアのあちこちにフリースペースが用意されており、ミーティングやランチ時に利用できます。

 

一人掛けのスペースもあるので、作業に集中したいときはここに籠ることも可能!

 

今週の金曜日にはJANOG39.5ミーティングをフリースペースで行います。
ストリーミング配信のお手伝いをすることになったので、こちらも今から楽しみです。

 

参加人数を増やしたようですので、ご興味のある方はぜひ足をお運びください!

最後に、DMM.comラボエンジニアブログで紹介されましたが、オライリー全巻が六本木オフィスに導入されました(パチパチ
エンジニアからの要望が多かったので導入されてうれしい!
オフィスもきれいになって働きやすい環境が整うとありがたい限りです。