産業技術大学院大学 InfoTalk仮想ネットワークの落とし穴   ~   秘匿されている致命的欠陥       ~  2013年3月15日(金) 19:00 – 20:30       産業技術大学院大学   株式会社データホテル      ...
自己紹介名前 伊勢幸一(いせ こういち)干支 寅 星座 いて座 性別 ♂ 血液型 AB コールサ゗ン JF1SSS1962年   北海道夕張市出身1986年   室蘭工業大学卒業後、日立設備エンジニゕリングに入社1989年   デジタルテクノロ...
仮想ネットワークのおさらい仮想ネットワークとは共有ネットワーク上にヘテロジニゕスな複数の仮想ネットワーク群を共存させるため、物理ネットワークを論理的に分離分割する技術であると同時に、プロバ゗ダーにある多種多様なリソースを集約し、単一のリソースと...
仮想ネットワークのおさらい はぁ?
Y.3011の仮想ネットワーク
IETF NVO3(Network Virtualization over L3)仮想ネットワークとはL3上にトンネルオーバレ゗するL2 もしくは L3ネットワーク。 (draft-ietf-nvo3-framework-02より)
NVO3の仮想データセンターモデル
仮想ネットワークとはITU-T Y.3011→ コンピューテゖングリソースIETF NVO3→ オーバーレ゗ネットワーク
本セッションでの仮想ネットワークとは  iDC事業者の立場ならば      ITU-Tモデル         だが    未来的すぐるのでIETF NVO3モデルとします
仮想ネットワークの分類 ◆エンドポ゗ントモデル ◆フゔブリックモデル
エンドポ゗ントモデル 物理ネットワークに接続された 物理サーバ、もしくは機器が トンネルオーバーレ゗の エンドポ゗ント
エンドポ゗ントモデル御三家◆ VXLAN (Virtual eXtensible LAN)◆ NVGRE (Network Virtualization using GRE)◆ STT (Stateless Transport Tunneling)
フゔブリックモデル物理ネットワークを機器ベースで統合集約し、仮想的に広帯域、高速かつ冗長性を提供
フゔブリックモデル御三家◆ MC-LAG          (ちょっと苦しいけど) (Multi-Chassis Link Aggregation Group)◆ TRILL  (Transparent Interconnection of  ...
フゔブリックモデルは?IEEEやIETFで標準化されたプロトコルを実装しただけでありこれといって致命的な欠陥が無く弄り甲斐が無い。(弱点はある)
エンドポ゗ントモデルは?◆ まだドラフト提案の段階◆ ドラフト提案者は実装ベンダー◆ 実装が先行しているため   ベンダーは引くに引けない◆ 仕様に穴が多い◆ 突っ込み所が満載ターゲット・ロックオン!
VXLAN■   VMware、Cisco、Arista等が押し■   フレームコンテナーはUDP■   ARP解決はマルチキャストグループ■   セグメントフゖールドは24bit (VNI)
VXLAN        VXLANフレームフォーマット         VXLANヘッダフォーマット
それほどでもない問題1) ARPリクエストをマルチキャストで解決   IGMP-Snooping対応要2) 非VXLAN対応セグメントとの    VLAN ID/VNIトランスレーション
ペ゗ロード長について◆ OuterIPヘッダ20byte◆ UDPヘッダ8byte◆ VXLANヘッダ8byte最低36byteのオーバーヘッドがある   → 最大ペ゗ロードが1464byteになる802.3(1514バ゗ト)や802.1Q(1...
どうするか? コンテナがUDPなんだからIPフラッグメント されるので問題無い。                                Etherヘッダ                                          ...
あれ? 一つの゗ーサネットフレームが(常に) 二つのフレームに分割されて搬送される       L2ス゗ッチやL3ルータの       パケット処理が2倍になる      パケット処理数が1/2 になる
なんと!ネットワーク処理能力が       半分       になる !?
フラッグメントされなきゃいい◆ IFのMTUを1400byteにしる数千数万の(仮想)マシンにログ゗ンして# ifconfig eth0 mtu 1400実行すんの?
それが゗ヤなら◆ 物理ネットワークMTUを1600byteにしる・そんなス゗ッチあんの?・あったとしても全部買い換えるの?・IEEE802.3, 802.1Q機器どーする?・互換性あんの?
結局VXLANを導入するということは◆    ネットワーク処理能力の低下◆    オペレーションコストの上昇◆    設備投資の負担
つまり ◆    サービスクォリテゖ          か ◆    エンジニゕのハート          か ◆    ビジネスベネフゖット  のどれを犠牲にするかの       三者択一
NVGRE■   MS、Arista、Intel、Dell、HP等が押し■   フレームコンテナーはIP■   ARP解決は特に指定なし■   セグメントフゖールドは24bit (VSID)
NVGREフレームとヘッダ ARP解決、非NVGREとの連携問題は VXLANとほぼ同じ。
フラッグメントに関する致命的欠陥NVGREフラグフゖールド(4bit)■第1ビットC   = Checksum = 0(MUST)■第2ビット    = No used = 0(MUST)■第3ビットK   = Key Option = 1(M...
つまりIPフラッグメントされると復元されたGREヘッダとペ゗ロードの正当性をチェックすることができない!
NVGREでは  なんぴとたりとも  GREペ゗ロードを  フラッグメント  させねぇ!          ©赤木軍馬
さすがにマ゗クロソフトは格が違った                                               © ブロントさんマ゗クロソフトの実装では           1500byte MTU DF=1          ...
結局NVGREを導入するということは◆   仮想OSはHyper-V◆ クラウドコントローラはSystem Center 2012 (MS)Virtual Machine Manager
つまり◆     ベンダー・ロック゗ン確定◆     OSSとの決別を意味する選択の自由を犠牲にするしかない
STT■   VMware(Nicira)だけが押し■   フレームコンテナーはTCP■   ARP解決はスルー(触れていない)■   セグメントフゖールドは64bit (CID)■   最大ペ゗ロードは64Kbyte
STTカプセリングシーケンス
STTヘッダ
STTのTCP風ヘッダTCPのシーケンス番号と応答確認番号を利用
ざっくり言うと■ MTU問題は無いように見えるが実はある■ TCP(風)処理が大きなオーバーヘッド■ Flagsが適当   URG = 0    ACK = 1    PSH = 1    RST = 0    SYN = 0    FIN = 0
TCPセグメンテーションオーバーヘッドはNICオフロードで解決!TSO : TCP Segmentation OffloadLRO : Large Receive Offload
だがしかし、もしも経路途中にTCPヘッダを解釈するノードがいるとするとIPS/IDSとかFireWallとかLoad BalancerとかTCP ProxyとかSTTセグメントを破棄するかもしんない
さすがにそれはマズ゗のでTCPと思われなければ良い。そうだプロトコル番号に6以外を使おう! 「IANAへゴー!」  あれ?
もしかするとプロトコル番号を6(TCP)以外にすると・・・?NIC Offload使えないじゃん?
結局STTを導入するということは◆   パケットドロップを許容          か◆   NICオフロードを断念  どちらにしても ネットワーク性能は    落ちる
つまり、  STTを導入するという事とネットワーク性能を犠牲にする  という事は等価である。
まとめてみると◆ VXLAN品質か人権か利益のどれかを犠牲◆ NVGRE上記に加え自由を犠牲◆ STT上記に加え性能を犠牲
そういう伊勢幸一は仮想ネットワークやSDNのアンチなのか?
ゕンチなのか?とんでもない!大推進派です!
その証拠に本も書いてますインプレスR&D出版SDN/OpenFlowで進化する仮想ネットワーク入門(Kindle版もあるよー)     http://www.amazon.co.jp/exec/obidos/ASIN/4844395750/p2...
ただし「推進」とは 盲信、狂信 ではない
盲信派、狂信派は 導入利活用 する人々を 不幸にする
推進派とは 導入利活用 する人々を幸せにしなけれ ばならない
推進派はメリット以上にデメリットを アピール するべき
認めましょう!SDN・仮想ネットワーク    の導入はネットワーク性能を低下      させ  運用コストを増大     させる
その上でSDN・仮想ネットワーク  によって享受する メリットが上であれば  導入するとよろし
メリットについてはSDN・仮想ネットワーク    盲信狂信派がイヤというほどアピール   しているので、ここでは割愛しますw
なぜSDN・仮想ネットワークをやるのか?アインシュタインはカーナビの精度を  上げるために相対性理論を考えた わけではない。
なぜSDN・仮想ネットワークをやるのか?訓練している以上の事は絶対にできない。無駄な事から必要な物が生まれる場合が多い。
以上
Upcoming SlideShare
Loading in …5
×

Info talk2013

9,891 views

Published on

2013.3.15 at Advanced Institute of Industrial Technology

1 Comment
41 Likes
Statistics
Notes
No Downloads
Views
Total views
9,891
On SlideShare
0
From Embeds
0
Number of Embeds
474
Actions
Shares
0
Downloads
160
Comments
1
Likes
41
Embeds 0
No embeds

No notes for slide

Info talk2013

  1. 1. 産業技術大学院大学 InfoTalk仮想ネットワークの落とし穴 ~ 秘匿されている致命的欠陥 ~ 2013年3月15日(金) 19:00 – 20:30 産業技術大学院大学 株式会社データホテル 伊勢幸一
  2. 2. 自己紹介名前 伊勢幸一(いせ こういち)干支 寅 星座 いて座 性別 ♂ 血液型 AB コールサ゗ン JF1SSS1962年 北海道夕張市出身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. 3. 仮想ネットワークのおさらい仮想ネットワークとは共有ネットワーク上にヘテロジニゕスな複数の仮想ネットワーク群を共存させるため、物理ネットワークを論理的に分離分割する技術であると同時に、プロバ゗ダーにある多種多様なリソースを集約し、単一のリソースとして提供することである (ITU-T Y.3011より)
  4. 4. 仮想ネットワークのおさらい はぁ?
  5. 5. Y.3011の仮想ネットワーク
  6. 6. IETF NVO3(Network Virtualization over L3)仮想ネットワークとはL3上にトンネルオーバレ゗するL2 もしくは L3ネットワーク。 (draft-ietf-nvo3-framework-02より)
  7. 7. NVO3の仮想データセンターモデル
  8. 8. 仮想ネットワークとはITU-T Y.3011→ コンピューテゖングリソースIETF NVO3→ オーバーレ゗ネットワーク
  9. 9. 本セッションでの仮想ネットワークとは iDC事業者の立場ならば ITU-Tモデル だが 未来的すぐるのでIETF NVO3モデルとします
  10. 10. 仮想ネットワークの分類 ◆エンドポ゗ントモデル ◆フゔブリックモデル
  11. 11. エンドポ゗ントモデル 物理ネットワークに接続された 物理サーバ、もしくは機器が トンネルオーバーレ゗の エンドポ゗ント
  12. 12. エンドポ゗ントモデル御三家◆ VXLAN (Virtual eXtensible LAN)◆ NVGRE (Network Virtualization using GRE)◆ STT (Stateless Transport Tunneling)
  13. 13. フゔブリックモデル物理ネットワークを機器ベースで統合集約し、仮想的に広帯域、高速かつ冗長性を提供
  14. 14. フゔブリックモデル御三家◆ MC-LAG (ちょっと苦しいけど) (Multi-Chassis Link Aggregation Group)◆ TRILL (Transparent Interconnection of Lots of Links)◆ SPB (Shortest Path Bridging)
  15. 15. フゔブリックモデルは?IEEEやIETFで標準化されたプロトコルを実装しただけでありこれといって致命的な欠陥が無く弄り甲斐が無い。(弱点はある)
  16. 16. エンドポ゗ントモデルは?◆ まだドラフト提案の段階◆ ドラフト提案者は実装ベンダー◆ 実装が先行しているため ベンダーは引くに引けない◆ 仕様に穴が多い◆ 突っ込み所が満載ターゲット・ロックオン!
  17. 17. VXLAN■ VMware、Cisco、Arista等が押し■ フレームコンテナーはUDP■ ARP解決はマルチキャストグループ■ セグメントフゖールドは24bit (VNI)
  18. 18. VXLAN VXLANフレームフォーマット VXLANヘッダフォーマット
  19. 19. それほどでもない問題1) ARPリクエストをマルチキャストで解決 IGMP-Snooping対応要2) 非VXLAN対応セグメントとの VLAN ID/VNIトランスレーション
  20. 20. ペ゗ロード長について◆ OuterIPヘッダ20byte◆ UDPヘッダ8byte◆ VXLANヘッダ8byte最低36byteのオーバーヘッドがある → 最大ペ゗ロードが1464byteになる802.3(1514バ゗ト)や802.1Q(1518バ゗ト)を一つのフレームにカプセリングできない!(M-in-Mで無い限り元々できないけどw)
  21. 21. どうするか? コンテナがUDPなんだからIPフラッグメント されるので問題無い。 Etherヘッダ ペイロード 1500byte 14byte(18byte) UDP VXLAN Ethernet フレーム ヘッダ ヘッダEthernet IP UDP VXLAN Ethernet フレーム1464byte分 ヘッダ ヘッダ ヘッダ ヘッダ Ethernet IP Etherフレーム ヘッダ ヘッダ 残り
  22. 22. あれ? 一つの゗ーサネットフレームが(常に) 二つのフレームに分割されて搬送される L2ス゗ッチやL3ルータの パケット処理が2倍になる パケット処理数が1/2 になる
  23. 23. なんと!ネットワーク処理能力が 半分 になる !?
  24. 24. フラッグメントされなきゃいい◆ IFのMTUを1400byteにしる数千数万の(仮想)マシンにログ゗ンして# ifconfig eth0 mtu 1400実行すんの?
  25. 25. それが゗ヤなら◆ 物理ネットワークMTUを1600byteにしる・そんなス゗ッチあんの?・あったとしても全部買い換えるの?・IEEE802.3, 802.1Q機器どーする?・互換性あんの?
  26. 26. 結局VXLANを導入するということは◆ ネットワーク処理能力の低下◆ オペレーションコストの上昇◆ 設備投資の負担
  27. 27. つまり ◆ サービスクォリテゖ か ◆ エンジニゕのハート か ◆ ビジネスベネフゖット のどれを犠牲にするかの 三者択一
  28. 28. NVGRE■ MS、Arista、Intel、Dell、HP等が押し■ フレームコンテナーはIP■ ARP解決は特に指定なし■ セグメントフゖールドは24bit (VSID)
  29. 29. NVGREフレームとヘッダ ARP解決、非NVGREとの連携問題は VXLANとほぼ同じ。
  30. 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. 31. つまりIPフラッグメントされると復元されたGREヘッダとペ゗ロードの正当性をチェックすることができない!
  32. 32. NVGREでは なんぴとたりとも GREペ゗ロードを フラッグメント させねぇ! ©赤木軍馬
  33. 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 = 1NVE側がMTUを自動調整してしまう
  34. 34. 結局NVGREを導入するということは◆ 仮想OSはHyper-V◆ クラウドコントローラはSystem Center 2012 (MS)Virtual Machine Manager
  35. 35. つまり◆ ベンダー・ロック゗ン確定◆ OSSとの決別を意味する選択の自由を犠牲にするしかない
  36. 36. STT■ VMware(Nicira)だけが押し■ フレームコンテナーはTCP■ ARP解決はスルー(触れていない)■ セグメントフゖールドは64bit (CID)■ 最大ペ゗ロードは64Kbyte
  37. 37. STTカプセリングシーケンス
  38. 38. STTヘッダ
  39. 39. STTのTCP風ヘッダTCPのシーケンス番号と応答確認番号を利用
  40. 40. ざっくり言うと■ MTU問題は無いように見えるが実はある■ TCP(風)処理が大きなオーバーヘッド■ Flagsが適当 URG = 0 ACK = 1 PSH = 1 RST = 0 SYN = 0 FIN = 0
  41. 41. TCPセグメンテーションオーバーヘッドはNICオフロードで解決!TSO : TCP Segmentation OffloadLRO : Large Receive Offload
  42. 42. だがしかし、もしも経路途中にTCPヘッダを解釈するノードがいるとするとIPS/IDSとかFireWallとかLoad BalancerとかTCP ProxyとかSTTセグメントを破棄するかもしんない
  43. 43. さすがにそれはマズ゗のでTCPと思われなければ良い。そうだプロトコル番号に6以外を使おう! 「IANAへゴー!」 あれ?
  44. 44. もしかするとプロトコル番号を6(TCP)以外にすると・・・?NIC Offload使えないじゃん?
  45. 45. 結局STTを導入するということは◆ パケットドロップを許容 か◆ NICオフロードを断念 どちらにしても ネットワーク性能は 落ちる
  46. 46. つまり、 STTを導入するという事とネットワーク性能を犠牲にする という事は等価である。
  47. 47. まとめてみると◆ VXLAN品質か人権か利益のどれかを犠牲◆ NVGRE上記に加え自由を犠牲◆ STT上記に加え性能を犠牲
  48. 48. そういう伊勢幸一は仮想ネットワークやSDNのアンチなのか?
  49. 49. ゕンチなのか?とんでもない!大推進派です!
  50. 50. その証拠に本も書いてますインプレスR&D出版SDN/OpenFlowで進化する仮想ネットワーク入門(Kindle版もあるよー) http://www.amazon.co.jp/exec/obidos/ASIN/4844395750/p2ptodwsl-22
  51. 51. ただし「推進」とは 盲信、狂信 ではない
  52. 52. 盲信派、狂信派は 導入利活用 する人々を 不幸にする
  53. 53. 推進派とは 導入利活用 する人々を幸せにしなけれ ばならない
  54. 54. 推進派はメリット以上にデメリットを アピール するべき
  55. 55. 認めましょう!SDN・仮想ネットワーク の導入はネットワーク性能を低下 させ 運用コストを増大 させる
  56. 56. その上でSDN・仮想ネットワーク によって享受する メリットが上であれば 導入するとよろし
  57. 57. メリットについてはSDN・仮想ネットワーク 盲信狂信派がイヤというほどアピール しているので、ここでは割愛しますw
  58. 58. なぜSDN・仮想ネットワークをやるのか?アインシュタインはカーナビの精度を 上げるために相対性理論を考えた わけではない。
  59. 59. なぜSDN・仮想ネットワークをやるのか?訓練している以上の事は絶対にできない。無駄な事から必要な物が生まれる場合が多い。
  60. 60. 以上

×