#L2overL3 参加メモ

2014/07/17らへんのもの。
※他ページからQiitaに移動

現在は、VXLANはRFC7348になっている。

@motonori_shindoさんによる、「L2 over L3トンネル方式について考える」のメモ。
資料はこちら。とてもありがたい。

目次

• VXLAN、NVGRE、STT、Geneveについて
• 疑問点など
• Geneve反対派の意見
• 質疑応答

VXLAN

• 正式名称は Virtual eXtensible Local Area Network。
• 他のもそうだけど、まだRFCになってない。draft。
• VXLANのモチベーションは？
  • 現在、VLANに問題をかかえてる。4096問題とか。
  • どうにかしたい。VLAN IDを拡張したい。VLANを置き換えたい。
• VNIは仮想ネットワークを識別するためのID。
• UDPを利用。UDPな理由はマルチパスを利用できるようにするため、が主軸。
• VXLANはHWで処理がしやすいように考えられたフレームフォーマットを持つ。
  • シンプル。ヘッダにはほぼVNIしかない。あとはRESERVEDが多い。VNIがあるかどうかのフラグ(常に1)くらいしかない。
• いろんなベンダ、とその機器がサポートしてて、エコシステムになってる。
• 従って相互接続性が高い。
• マルチパスのため、元パケットのヘッダをなんかしらハッシュして、カプセルのsource portに設定する。
• destination portは4789。

NVGRE

• 正式名称は Network Virtualization using Generic Routing Encapsulation。
• これもまだdraft。でてきたのはほとんどVXLANとおなじ。
• やっぱり有名企業がおおい。Microsoft社が中心だったりする。
• これもシンプル。やっぱり仮想ネットワークでの利用が前提で、VirtualSubnetIDとFlowIDをもってる。
• FlowIDはマルチパスのために用意されたもの。GREは位置的にL4であり、そのヘッダにはポートが無いから。
• NVGREは新たカプセルではなく、GREそのもの。
  • GREは柔軟なフレーム構造になってて、こういうフィールドがある、ないをフラグで示せる形をしてる。
  • GREは可変長のカプセルで、いらないフィールドはつけなかったりする。
  • NVGREはGREの１個のフィールド（Key）だけをつかう、っていう規定をしてるので、NVGRE自体は固定長。
• マルチパスは理論上できるらしいが･･･
• 重要な差別化ポイントは、Windowsと親和性が高いこと。
  • 逆にWindows以外ではあんま使われてない？
• ヘッダにはProtocolTypeがあるが、NVGREはペイロードにEthernetフレームを置くことを前提にしているため、0x6558固定。
• NVGREというかGREはポートがないのでVXLANみたいにsource portとかでマルチパス実現ができない。
  • そこでFlowID使うが、GREの中身覗いてFlowID見る機器は少なくて、やはりマルチパスの力を発揮できないことが多い。
  • サポートしてるルータはHuawai社のもの。
  • レイヤ上のだとF5 Network社もサポートしてる。
  • NICだとEmulex、Mellanoxがサポートしてて、NVGREオフロードに対応してるらしい。
    • Keyまで見てハッシュする機能があるかは不明
• VXLANほどサポートされてないのが実情。

STT

• 正式名称はStateless Transport Tunneling。
• VMWare社（というかNicira社）の提唱してるL2 over L3カプセリング方式。
• これもドラフト。RFCはInformationalを目指している？
• VXLANとNVGREあるのに、なぜSTTつくったのか？
  • 性能。他のに比べるととパフォーマンスをだせる。
    • TSOをフル活用する。コンテキストスイッチングを減らましょう。
      • カプセリングを**TCPのようなもの(見た目はTCP)**で行い、NICにオフロードさせる。
      • 実際はTCPではないので、そこはStateless。
      • STTヘッダは分割された最初のセグメントにしか付かない。
  • 拡張性。もっと多くのContextを運ばないといけないと思ったから。
    • VXLANとかで運んでた情報って、ほとんどVNIとかVSID。仮想ネット識別するだけのもの。
    • 仮想ネットワーク作るには、ネットワークの識別だけすればいいわけじゃないと考えた。
    • もっと複雑なものいるはず。ServiceChainingとか。
    • ContextIDという用途自由な64Bitフィールドをもっていて、ここをどう使うかがコントロールプレーン実装ベンダの腕の見せ所。
• ソフトウェア寄りの仕様になっている。
  • どういうことかというと、endがHypervisorになることを考えている。
  • NICさえTSOをサポートしていて、endがソフトウェアであればよく、同時にSTTを使える条件でもある。TSOのないNICは殆どない。
  • 逆に、STTをサポートするようなハードウェアは今後も恐らくでてこない。
• DC内での利用がメイン。
• マルチパスをうまく効かせるために、TCPのようなもののsource portにペイロードのヘッダのハッシュを入れている。
• destination portは7471を申請中。

Geneve

• 正式名称はGeneric Network Virtualization Encapsulation。

• 読み方はジュニーヴ、らしい？ジュネイヴっていう人もいる。

• 最近できたばっかり。draft。

• Geneveのモチベーション

  • 今までのでは満たせないのを満たそうと。
    • 拡張性。固定長のフレームだと拡張の余地はない。STTは64Bitなんで今は十分かもしれないけど、将来たりないかもしれない。
    • Service Chainingとかをできるようにしたい。これやろうとするとき固定長カプセルだと厳しいかもしれない。
    • TSOも活用したい。
    • ※可変長かつTSOはどこからTCPセグメントかわからないので難しい。
  • 拡張したもの
    • TVL。OAMとかも入った。あと、TSOすべきかどうかをNICが判断できるように。
    • ProtocolTypeも持ってる。Service Chainingが目的らしい。
    • VNIも持ってる。
    • 要するにVXLANにProtocolTypeとオプションが付いたようなデータ構造。

• 実装は？

  • OVSにマージされた。master branchに入ってるから、自分でbuildしましょう。
  • 肝心のoptionがまだ使えない。というか、どういうoptionがあるのか決まってない。
    • 別のdraftがでてくる予定。

• Geneveの解析は？

  • WiresharkにもGeneveのdissectorがはいったから解析できる。これもmaster branchに入ってるから、自分でbuildしましょう。

• 使えそうなの？

  • 真価を発揮するのはGeneveを認識できる、Geneve-AwareなNICができて、オプションつけられてTSOもできるようになったとき。
  • まだそういうNICは世の中にない。これから。

疑問点など

• Geneveはほかのトンネルを置き換える形になっていくのか？

  • VXLANを置き換えることになるの？

    • NO。VXLANのエコシステムは非常に大きいので、Geneveで同じことができるようになってもたぶんVXLANはなくならないし、これからも成長するはず。

  • STTの置き換えは？

    • 短期的にはNo、長期だとあるかも？GeneveはOVSに実装されたけど、すぐ置き換えられることはない。まだサポートしてるNICがないし。
    • そういうNICの普及に伴って、もしかすると徐々にSTTはなくなっていくかも。

  • NVGREは？

    • これも短期的にはNo、長期だとあるかも･･･
    • NVGREの運命はほぼMicrosoft社が握っているので、もしWindowsでGeneveがサポートされて、Azureでも利用可能になって、とかいう事になると、なくなっていくかも。

• トンネルの方式って、結局どれが主流なの？

  • どれかが主流ってこともない。適材適所。
  • Hypervisor - Hypervisor はいまのとこSTTでやるのは理に適っているし、ハードウェアをendにするならVXLANとか。
  • 混在しててもいいし、使い分けが重要。

Geneve反対派の意見

Geneve反対派の方々も当然いる。

• 新しいの作るんじゃなくて既存のVXLANとかの拡張でやってよ。
• ServiceChainingとかMedatadaを運びたいニーズがあるし、そういう団体あるのもわかるけど、そのへんとカプセリング方式ををBindすべきじゃないでしょ。
  • カプセリング自体の拡張性にしなくていいでしょ、という事。
  • 別の団体で別のヘッダを定義しようとしてるんだし、混ぜなくてもいいんじゃないの。
  • ※ ⇒でも、Geneveの拡張性はServiceChainingとかMetadataのためとは限らない。
• VNIは24Bitじゃ足りないだろう。

回答？

• 既存拡張でできないか？の主張

  • L2TPv3　Static Tunnelingでどう？
  • Signalingつかわずに両端に静的に設定をして、カプセルとしてだけ使うこともできる（L2TP StaticTunnel）。PseudoWireとか。
  • L2TP自体はTransportFreeだし、マルチパスも満たせる。
  • L2TPには昔、オフセットがあったから、それを使ってどこからTCPが始まるかもわかってTSOいけるんじゃないか？

• VXLAN拡張は？の主張

  • VXLAN GenericProtocolExtention （eVXLAN、VXLAN-gpe）
    • 元々RESERVEDだったエリアにNextProtocolいれたくらい。あとバージョンとかOAM。
    • NextProtocolはNSHをうまくカプセリングする為にいれてみたやつ。8ビットしかないので、本来のプロトコルタイプとは違うマップ値が入る。
    • 実装はCisco ACIですでに存在。
    • 拡張性はないけどNSHに対応してService Chainingすることはできるかもね。

質疑応答コーナー　(拾い切れなかった)

• アンダーレイで考慮することはありますか？

  • あんまりない。けど素性のいいネットワークのほうがいい。
  • あんまり縛りはないし、既存を置き換えるものではない。オーバーレイだからなんでもうごく。

• DCを跨いだ通信をやろうとしたときにマッチするのはどれ？

  • WANに向いてるかどうかって意味ではどれも大差ない。本質的には。
  • 実装に縛られるところはある。MTUのサイズとか。
  • どのカプセリングで、というのはどのトンネルでも大差ない。