「仮想ネットワークの落とし穴～秘匿されている致命的欠陥～」を聞いてきた

きのう、産業技術大学院大学で@ibuchoの

　仮想ネットワークの落とし穴
　～秘匿されている致命的欠陥～

を聞いてきた。その内容をメモメモ

---

・前フリの話
　内容は挑戦的ではない。
　ここ１，２年ＳＤＮをｄｉｓるのは、タブーとなっている
　これでやれるのは、伊勢さんとさくらインターネットの大久保さんくらい
　秘匿：口に出せない。重大な秘密ではない


・伊勢さんの自己紹介

・仮想ネットワークのおさらい
　　ねーとわーくばーちゃりぜーしょん
　　定義：
　　　ＩＴＵ－Ｔ　Ｙ．３０１１について
　　　　図をかくとわかる
　　　　　サービス
　　　　　　↑
　　　　　　↓
　　　　　論理的に分割：りんぷ：ロジカルアイソレーション
　　　　　　↑
　　　　　　↓
　　　　　仮想リソース層：集約
　　　　　　↑
　　　　　　↓
　　　　　物理リソース
　　　→コンピューティングリソースも含む
　　りんぷ：ＮＴＴが研究、未来的

　　ＩＥＴＦ　ＮＶＯ３の定義
　　　Ｌ３にトンネルオーバーレイするＬ２，Ｌ３ネットワーク
　　　　　→ネットワーク
　　　仮想的なデータセンター？

　　　ＴＥＳがサービスなどのエンドポイント
　　　ＮＶＥが途中にいて、トンネリングする
　　　今回はＩＥＴＦのほうを対象

・仮想ネットワークの分類
　　エンドポイントモデル
　　　　ＮＶＯ３の仮想ネットワークそのもの
　　　　ハイバーバイザーが物理ネットワークにつながっている
　　　　　　なんらかのトンネリングを張る

　　　　御三家
　　　　　ＶＸＬＡＮ
　　　　　ＮＶＧＲＥ
　　　　　ＳＴＴ

　　ファブリックモデル
　　　　物理ネットワークを集約する
　　　　　従来どおりのネットワークを集約→広帯域

　　　　御三家？２巨頭
　　　　　　ＭＣ－ＬＡＧ
　　　　　　ＴＲＩＬＬ（とりる）
　　　　　　ＳＰＢ:ＩＥＥＥ
　 　スパニングツリー
　　　　 →ラピッドスパニングツリー
　　　　　　　　 →マルチスパニングツリー・・の後継
　　　　弱点はあるけど、致命的欠陥がない
　　　　ＴＲＩＬＬ：ブロケードさん
　　　　ＳＰＢ：あばいやさん
　　　　　→ブロケードさんＶＳあばいやさん？

・エンドポイントモデルは？
　　まだドラフト
　　実装が先行：引くに引けない
　　仕様に穴が多い

・ＶＸＬＡＮ
　　去年人気高かった
　　VMWareとCiscoが押し、aristaは八方美人
　　フレームコンテナはＵＤＰ
　　アドレス解決：
　　　　ブロードキャストできない→マルチキャスト
　　　　　（ほかのにも出てくる論点）
　　　　セグメントフィード(ＶＬＡＮＩＤに相当）ＶＮＩは
　　　　　　２４ビット
　　　　いままで、最大のＶＬＡＮは１２ビット→４Ｋだった
　　　　ＶＴＥＰ：エンドポイントのハイパーバイザー
　　シンプルなヘッダ

　それほどでもない問題
　　　マルチキャストで解決
　　　　　全てマルチキャスト設定
　　　　　全てのポートにマルチキャスト：IGMP-Snooping
　　　　　いきなりマルチキャスト・・？
　　　非ＶＸＬＡＮセグメント
　　→すべてのエンドポイントに影響
　致命的問題（ＶＸＬＡＮだけじゃないけど）
　　　イーサネットフレームをカプセリングして、
　　　　イーサネットフレームを送る
　　　→おおきさたりない。
　　　→２つのパケットにわかれる→ＩＰフラグメント

　　　ＵＤＰだから問題ない
　　　　　→ただし、パケット処理は２倍
　　　　　→がんがん使うと、ネットワーク処理能力は１／２？
　　　　　　　　→ショートパケットは落ちないけど・・

　　　フラグメントされなければいい？
　　　　　→ＭＴＵを全部１４００にすれば・・・
　　　　　→って、すべてのマシンに？

　　　VMware的には、物理ネットワークＭＴＵを1600へ・・と・・
　　　　　→そんな機械あるの？全部買いかえるの？

　　　ＶＸＬＡＮを導入
　　　　・ネットワーク処理低下（フラグメントで１／２）
　　　　・エンジニアのハート（ＭＴＵ設定）
　　　　・機器を入れ替える（全部買い替え？）


・ＮＶＧＲＥ
　ＭＳ，Ｉｎｔｅｌそしてありすた
　ＡＲＰ解決は詳しく書いてないけど、マルチキャスト？
　セグメントフィードは２４ビット（ＶＳＩＤ）

　プロトコルはＧＲＥ

　致命的問題：フラグメント→かなり致命的
　　　ＧＲＥヘッダーのフラグ：間違えたら大変！
　　　ＧＲＥはチェックサムがあるところが・・・
　　　→ＩＰペイロードにチェックサムがない
　　　　　くずれたら、わからない！！！
　「ＮＶＧＲＰでは、なんぴとたりともＧＲＥペイロード
　　をフラグメントしてはいけない」

　マイクロソフトの実装
　　　ＭＴＵ　ＤＦ＝１
　　　ＩＣＰＭ　エラー：データグラムがおおきいよ
　　　これくらいにしてね！とＭＴＵを送る
　　→ＮＶＥ側がＭＴＵを自動調整するのでＯＫ！
　　→ってことは、仮想ＯＳは、Ｈｙｐｅｒ－Ｖ
　　　クラウドコントローラーはSystem Center 2012
　　→ベンダーロックイン確定！

・ＳＴＴ
　　VMware（Niciraのひと）だけが押し
　　フレームコンテナーにＴＣＰ
　　セグメントフィールド(コンテキストＩＤ：ＣＩＤ）
　　最大ペイロード６４ＫＢｙｔｅ
　　ＮＩＣが図に描いてある
　　　イーサネットフレーム
　　　　　→ＳＴＴフレーム
　　　　　　　→ＳＴＴセグメント
　　　　　　　　　　→ＩＰパケット　
　　ＴＣＰのシーケンス番号、ＡＣＫ番号をＳＴＴ用に使う
　　　フォーマットは同じだけど、中身は違う
　　　　→ＳＴＴ以外だと、普通のＴＣＰと思う

　　ＭＴＵ問題は実はある
　　ＴＣＰの実装プログラム大変
　　ＦＬＡＧ若干違う
　　　　→処理負荷大きい：ＮＩＣオフロード
　　　　　→ＴＣＰ／ＩＰ処理をＮＩＣで行うこと

　　ただし、エンド　エンド間に、ファイヤーウォールとか
　　ＴＣＰを読むやつがいると・・・
　　　　わけのわからないフレームで落とされる
　　　　→ＴＣＰじゃないと判断してもらえば・・・
　　　　　　スルーする？
　　　　　　→ＩＡＮＡへ
　　　　　　　ちょっとまて、
　　　　　　　ＮＩＣ　オフロードはＴＣＰ６ばんじゃないいと
　　　　　　　しょりしないお
　　パケットドロップを許容するか、ＮＩＣオフロード断念
　　→ネットワーク性能は落ちる

本も書いてます
　ＳＤＮ／ＯｐｅｎＦｌｏｗで進化する
　仮想ネットワーク入門