2013.3.15 at Advanced Institute of Industrial Technology

1. 産業技術大学院大学 InfoTalk
仮想ネットワークの落とし穴
～ 秘匿されている致命的欠陥 ～
2013年3月15日(金) 19:00 – 20:30
産業技術大学院大学
株式会社データホテル 伊勢幸一

2. 自己紹介
名前 伊勢幸一(いせ こういち)
干支 寅 星座 いて座 性別 ♂ 血液型 AB コールサ゗ン JF1SSS
1962年 北海道夕張市出身
1986年 室蘭工業大学卒業後、日立設備エンジニゕリングに入社
1989年 デジタルテクノロジーに入社
1996年 株式会社スクウェゕに入社( FF7始動)
1997年 SQUARE USA INC. に出向 (TSW製作)
2000年 東京本社帰任 (POL/FF11開発)
2005年 株式会社ラ゗ブドゕに入社
2008年 執行役員CTA 情報環境技術研究室長に就任
2012年 株式会社データホテルに社名変更 現在に至る
課外活動
2009 - InteropTokyoプログラム委員
2010 - クラウド利用促進機構(CUPA) 総合ゕドバ゗ザー
2011 - オープンクラウドキャンパス チェゕ
2011 - ICTEPC ネットワーク教育ワーキンググループ 主査
2012 - オープンクラウド実証実験タスクフォース座長

3. 仮想ネットワークのおさらい
仮想ネットワークとは
共有ネットワーク上にヘテロジニゕスな複数の
仮想ネットワーク群を共存させるため、
物理ネットワークを論理的に分離分割する
技術であると同時に、プロバ゗ダーにある
多種多様なリソースを集約し、
単一のリソースとして提供することである
(ITU-T Y.3011より)

4. 仮想ネットワークのおさらい
はぁ？

5. Y.3011の仮想ネットワーク

6. IETF NVO3(Network Virtualization over L3)
仮想ネットワークとは
L3上にトンネルオーバレ゗する
L2 もしくは L3ネットワーク。
(draft-ietf-nvo3-framework-02より)

7. NVO3の仮想データセンターモデル

8. 仮想ネットワークとは
ITU-T Y.3011
→ コンピューテゖングリソース
IETF NVO3
→ オーバーレ゗ネットワーク

9. 本セッションでの仮想ネットワークとは
iDC事業者の立場ならば
ITU-Tモデル
だが
未来的すぐるので
IETF NVO3モデルとします

10. 仮想ネットワークの分類
◆エンドポ゗ントモデル
◆フゔブリックモデル

11. エンドポ゗ントモデル
物理ネットワークに接続された
物理サーバ、もしくは機器が
トンネルオーバーレ゗の
エンドポ゗ント

12. エンドポ゗ントモデル御三家
◆ VXLAN
(Virtual eXtensible LAN)
◆ NVGRE
(Network Virtualization using GRE)
◆ STT
(Stateless Transport Tunneling)

13. フゔブリックモデル
物理ネットワークを機器ベースで
統合集約し、仮想的に広帯域、高速
かつ冗長性を提供

14. フゔブリックモデル御三家
◆ MC-LAG (ちょっと苦しいけど)
(Multi-Chassis Link Aggregation Group)
◆ TRILL
(Transparent Interconnection of
Lots of Links)
◆ SPB
(Shortest Path Bridging)

15. フゔブリックモデルは？
IEEEやIETFで標準化された
プロトコルを実装しただけであり
これといって致命的な欠陥が無く
弄り甲斐が無い。(弱点はある）

16. エンドポ゗ントモデルは？
◆ まだドラフト提案の段階
◆ ドラフト提案者は実装ベンダー
◆ 実装が先行しているため
ベンダーは引くに引けない
◆ 仕様に穴が多い
◆ 突っ込み所が満載
ターゲット・ロックオン！

17. VXLAN
■ VMware、Cisco、Arista等が押し
■ フレームコンテナーはUDP
■ ARP解決はマルチキャストグループ
■ セグメントフゖールドは24bit (VNI)

18. VXLAN
VXLANフレームフォーマット
VXLANヘッダフォーマット

19. それほどでもない問題
1) ARPリクエストをマルチキャストで解決
IGMP-Snooping対応要
2) 非VXLAN対応セグメントとの
VLAN ID/VNIトランスレーション

20. ペ゗ロード長について
◆ OuterIPヘッダ20byte
◆ UDPヘッダ8byte
◆ VXLANヘッダ8byte
最低36byteのオーバーヘッドがある
→ 最大ペ゗ロードが1464byteになる
802.3(1514バ゗ト)や
802.1Q(1518バ゗ト)を
一つのフレームにカプセリングできない！
(M-in-Mで無い限り元々できないけどｗ）

21. どうするか？
コンテナがUDPなんだからIPフラッグメント
されるので問題無い。
Etherヘッダ
ペイロード 1500byte
14byte(18byte)
UDP VXLAN
Ethernet フレーム
ヘッダ ヘッダ
Ethernet IP UDP VXLAN
Ethernet フレーム1464byte分
ヘッダ ヘッダ ヘッダ ヘッダ
Ethernet IP Etherフレーム
ヘッダ ヘッダ 残り

22. あれ？
一つの゗ーサネットフレームが(常に)
二つのフレームに分割されて搬送される
L2ス゗ッチやL3ルータの
パケット処理が2倍になる
パケット処理数が1/2 になる

23. なんと！
ネットワーク処理能力が
半分
になる !?

24. フラッグメントされなきゃいい
◆ IFのMTUを1400byteにしる
数千数万の(仮想)マシンにログ゗ンして
# ifconfig eth0 mtu 1400
実行すんの？

25. それが゗ヤなら
◆ 物理ネットワークMTUを1600byteにしる
・そんなス゗ッチあんの？
・あったとしても全部買い換えるの？
・IEEE802.3, 802.1Q機器どーする？
・互換性あんの？

26. 結局VXLANを導入するということは
◆ ネットワーク処理能力の低下
◆ オペレーションコストの上昇
◆ 設備投資の負担

27. つまり
◆ サービスクォリテゖ
か
◆ エンジニゕのハート
か
◆ ビジネスベネフゖット
のどれを犠牲にするかの
三者択一

28. NVGRE
■ MS、Arista、Intel、Dell、HP等が押し
■ フレームコンテナーはIP
■ ARP解決は特に指定なし
■ セグメントフゖールドは24bit (VSID)

29. NVGREフレームとヘッダ
ARP解決、非NVGREとの連携問題は
VXLANとほぼ同じ。

30. フラッグメントに関する致命的欠陥
NVGREフラグフゖールド(4bit)
■第1ビットC = Checksum = 0(MUST)
■第2ビット = No used = 0(MUST)
■第3ビットK = Key Option = 1(MUST)
■第4ビットS = Seq NUM = 0(MUST)
IPペ゗ロードにチェックサムが無い?

31. つまりIPフラッグメントされると
復元された
GREヘッダとペ゗ロードの
正当性をチェックする
ことができない！

32. NVGREでは
なんぴとたりとも
GREペ゗ロードを
フラッグメント
させねぇ！
©赤木軍馬

33. さすがにマ゗クロソフトは格が違った
© ブロントさん
マ゗クロソフトの実装では
1500byte MTU DF=1
ICMP error “Datagram too big”
Tenant Type=3, code=4
VM Next-hop MTU = 1400bye Hyper-V
Windows (NVGRE NVE)
RHEL
CentOS 1400byte MTU DF = 1
NVE側がMTUを自動調整してしまう

34. 結局NVGREを導入するということは
◆ 仮想OSはHyper-V
◆ クラウドコントローラは
System Center 2012 (MS)
Virtual Machine Manager

35. つまり
◆ ベンダー・ロック゗ン確定
◆ OSSとの決別を意味する
選択の自由を犠牲にするしかない

36. STT
■ VMware(Nicira)だけが押し
■ フレームコンテナーはTCP
■ ARP解決はスルー(触れていない)
■ セグメントフゖールドは64bit (CID)
■ 最大ペ゗ロードは64Kbyte

37. STTカプセリングシーケンス

38. STTヘッダ

39. STTのTCP風ヘッダ
TCPのシーケンス番号と応答確認番号を利用

40. ざっくり言うと
■ MTU問題は無いように見えるが実はある
■ TCP(風)処理が大きなオーバーヘッド
■ Flagsが適当
URG = 0
ACK = 1
PSH = 1
RST = 0
SYN = 0
FIN = 0

41. TCPセグメンテーションオーバーヘッドは
NICオフロードで解決！
TSO : TCP Segmentation Offload
LRO : Large Receive Offload

42. だがしかし、もしも
経路途中にTCPヘッダを解釈する
ノードがいるとすると
IPS/IDSとか
FireWallとか
Load Balancerとか
TCP Proxyとか
STTセグメントを
破棄するかもしんない

43. さすがにそれはマズ゗ので
TCPと思われなければ良い。そうだ
プロトコル番号に6以外を使おう！
「IANAへゴー！」
あれ?

44. もしかすると
プロトコル番号を６(TCP)以外に
すると・・・？
NIC Offload
使えないじゃん?

45. 結局STTを導入するということは
◆ パケットドロップを許容
か
◆ NICオフロードを断念
どちらにしても
ネットワーク性能は
落ちる

46. つまり、
STTを導入するという事と
ネットワーク性能を犠牲にする
という事は等価である。

47. まとめてみると
◆ VXLAN
品質か人権か利益のどれかを犠牲
◆ NVGRE
上記に加え自由を犠牲
◆ STT
上記に加え性能を犠牲

48. そういう伊勢幸一は仮想ネットワークやSDNの
アンチ
なのか?

49. ゕンチなのか？
とんでもない!
大推進派です!

50. その証拠に
本も書いてます
インプレスR&D出版
SDN/OpenFlowで進化する
仮想ネットワーク
入門
(Kindle版もあるよー）
http://www.amazon.co.jp/exec/obidos/ASIN/4844395750/p2ptodwsl-22

51. ただし
「推進」とは
盲信、狂信
ではない

52. 盲信派、狂信派は
導入利活用
する人々を
不幸にする

53. 推進派とは
導入利活用
する人々を
幸せにしなけれ
ばならない

54. 推進派は
メリット以上に
デメリットを
アピール
するべき

55. 認めましょう！
SDN・仮想ネットワーク
の導入は
ネットワーク性能を低下
させ
運用コストを増大
させる

56. その上で
SDN・仮想ネットワーク
によって享受する
メリットが上であれば
導入するとよろし

57. メリットについては
SDN・仮想ネットワーク
盲信狂信派が
イヤというほどアピール
しているので、
ここでは割愛しますｗ

58. なぜSDN・仮想ネットワークをやるのか？
アインシュタインは
カーナビの精度を
上げるために
相対性理論を考えた
わけではない。

59. なぜSDN・仮想ネットワークをやるのか？
訓練している以上の事は
絶対にできない。
無駄な事から必要な物が
生まれる場合が多い。

60. 以上