Upload
motonori-shindo
View
3.177
Download
6
Embed Size (px)
DESCRIPTION
各種 L2 over L3 encapsulation 方式について比較検討をします。VXLAN, NVGRE, STT, Geneve, L2TP static tunneling, VXLAN-gpe (eVXLAN) などをカバーしています。
Citation preview
© 2014 VMware Inc. All rights reserved.
L2 over L3 トンネル方式について考える VXLAN、NVGRE、STT、Geneve などの各方式比較検討
ヴイエムウェア(株) ネットワーク&セキュリティー事業部 テクニカル・リーダー 進藤 資訓 / @motonori_shindo 2014 / 07 / 16
Tunneling vs Encapsulation • トンネリング・プロトコル
– Signaling + Encapsulation • 通常なにかしらの “シグナリング” を持ち、トンネルの維持・管理をする機構がプトロコルに含ま
れている • Encapsulation も必要
– 例) PPTP、L2TP、IPsec (IKE)、など
• Encapsulation – なにかをなにかで “くるむ” 仕組み – 例) GRE、VXLAN、NVGRE、STT、(Ethernet, IP, TCP, ….)
• 今日お話ししするのは厳密には “Encapsulation” です。
• また、コントロールプレーンのお話は(とても大切ですが)しません。 2
代表的な L2 over L3 encapsulation
• GRE (Generic Routing Encapsulation) *
• VXLAN (Virtual Extensible LAN)
• NVGRE (Network Virtualization using GRE)
• STT (Stateless Transport Tunneling)
* 厳密に言うと GRE は L2 over L3 とは限りません。
VXLAN
• Cumulus / Arista / Broadcom / Cisco / VMware / Citrix / RedHat らが提唱 – draft-mahalingam-dutt-dcops-vxlan-09.txt
• VLAN ID (12bit) を VNI (24bit) に拡張 • UDP/IP で Encapsulation
– L3 オーバーレイ – マルチパス可能
• Ethernet Frame を仮定 • ハードウェアで処理し易いように設計
• エコシステムの形成
VXLAN ヘッダー
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|R|R|R|I|R|R|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VXLAN Network Identifier (VNI) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fabric のトレンド
• Service Oriented Architecture の台頭
• 2 or 3階層のネットワークから Leaf /
Spineネットワークへ
• 非常に高い密度と帯域の要求
• Layer 3 で ECMP
• オーバーサブスクライブの低減
• 低く、かつ、一様な遅延特性
• Wire & configure once なネットワーク
• 一様なネットワーク設定
WAN/Internet
WAN/Internet
マルチパス特性
• 背景 – East-West トラフィックの増大に対応するため、マルチパスによる Fabric ネットワークが
広く用いられるようになってきている。
• 要件 – 1つのフローは同じパスを通ること – マルチパスを有効に活用するために十分なエントロピーを持つこと
VXLAN のマルチパス
VXLAN (8) UDP (8) IP (20)
Hash (src/dst MAC addr, src/dst IP addr, src/dst port number, etc.) *
dst port = 4789 src port = Hash()
Ether IP TCP Data
元パケット
* 何をハッシュするか、どのようにハッシュするかは厳密には決められておらず、実装依存です。
VXLAN エコシステム • スイッチ・ルータ
– Arista、Brocade、Cisco、Cumulus、DELL、HP、Huawei、Juniper、Open vSwitch、Pica8
• オペレーティングシステム – Linux、VMware
• アプライアンス – A10、Citrix、F5
• テスター – IXIA、Spirent
• ASIC / NIC – Broadcom、Intel (Fulcrum)、Emulex、
Mellanox
• Cloud Orchestrator – CloudStack、OpenStack、vCAC 9
Note: this is not an exhaustive list
NVGRE
• Microsoft / Arista / Intel / Google / HP / Broadcom / Emulex らが提唱 – draft-sridharan-virtualization-nvgre-04.txt
• 24bit の Virtual Subnet ID (VSID) と 8bit の FlowID
• Encapsulation は GRE のまま – Key Field に VSID + FlowID – L3 オーバーレイ – マルチパス可能(理論上)
• Windows との親和性
NVGRE ヘッダー
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| |1|0| Reserved0 | Ver | Protocol Type 0x6558 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Virtual Subnet ID (VSID) | FlowID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NVGRE のマルチパス
GRE (8) IP (20)
Hash (src/dst MAC addr, src/dst IP addr, src/dst port number, etc.) *
FlowID = Hash()
Ether IP TCP Data
元パケット
* 何をハッシュするか、どのようにハッシュするかは厳密には決められておらず、実装依存です。
ルータ・スイッチは GRE の Key Field まで含めて ECMP する必要があ
る!
NVGRE エコシステム • スイッチ・ルータ
– Huawei – Arista や Brocade も対応は表明しているが、まだモノは出ていない??
• オペレーティングシステム – Microsoft (Windows Server 2012 R2)
• アプライアンス – F5
• ASIC / NIC – Emulex、Mellanox
• Cloud Orchestrator – System Center 2012 R2
13 Note: this is not an exhaustive list
STT (Stateless Transport Tunneling) • VMware が提唱する L2 over L3 Encapsulation 手法
– draft-davie-stt-06.txt
• Why yet another L2 over L3 encapsulation ? – 性能 – 多くのコンテクスト情報 – マルチパス可能 – ソフトウェア指向
TSO (TCP Segmentation Offload) • 最近の(ここ4〜5年に出た)NIC には様々なハードウェア・アクセラレーション機能
が搭載されている – RSS、GSO/TSO、Checksum Offload、etc.
• TSO は、通常 OS(ソフトウェア)が行わなければいけないSegmentation 処理をNICがハードウェアで行ってくれる – 最大 64K bytes のパケットを送れる à Context Switch を劇的に減らせる
• NICには “TCP” に見えるようなパケットで Encapsulation してやる事により、TSO のメリットを享受できる!
Encapsulation / Segmentation 処理の流れ
STT (18) TCP’ (20) IP (20)
Payload 1 STT (18) TCP’ (20) IP (20)
Payload 2 TCP’ (20) IP (20)
Payload n TCP’ (20) IP (20)
L2 Frame (up to ≒ 64K)
呍呍呍呍
(HWによる) Segmentation
処理
TCP-like ヘッダー 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number(*) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number(*) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
STT ヘッダー
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Flags | L4 Offset | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max. Segment Size | PCP |V| VLAN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Context ID (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |
スループットと CPU 使用率
0
10
20
30
40
50
60
70
80
90
100
0
1
2
3
4
5
6
7
8
9
10
Linux Bridge OVS Bridge OVS-GRE OVS-STT
スループット CPU (Receive) CPU (Send)
(Gbps) (%) 出典: http://networkheresy.com/2012/06/08/the-overhead-of-software-tunneling/
STT のマルチパス
STT (18) TCP’ (20) IP (20)
Hash (src/dst MAC addr, src/dst IP addr, src/dst port number, etc.)
dst port = 7471 (TBD) src port = Hash()
Ether IP TCP Data
元パケット
* 何をハッシュするか、どのようにハッシュするかは厳密には決められておらず、実装依存です。
Geneve (Generic Network Virtualization Encapsulation) • VMware, Microsoft, RedHat, Intel が提唱する新たな encapsulation
– draft-gross-geneve-00.txt
• ゴール – 拡張性を備えること
• Service Chaining や Metadata のサポート
– NIC 等のオフロード機能を有効に活用できること – これら2つを「同時に」満たすこと!
• 特徴 – Option フィールドで TLV 形式の情報を追加できる – ハードウェアが TSO を実行できるように、どこから TSO すべきかを NIC が判断可能 – OAM や Option 解釈必須の有無などを指定可能
21
Geneve Header & Option Header Geneve Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| Opt Len |O|C| Rsvd. | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Virtual Network Identifier (VNI) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Class | Type |R|R|R| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Option Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Geneve 実装 • Open vSwitch (OVS)に実装され、master branch にマージ
– VNI の指定が可能 – Geneve Options の指定は(まだ)できない – OAM フラグを立てることはできない? – Critical フラグは Critical Options があれば自動的に立つ(ようにコード上は読める)
• Wireshark に Geneve の dissector が実装され、master branch にマージ
• Geneve に対応した NIC は今後リリース予定
23
Running Geneve on Open vSwtich
24
host-1:~$ sudo ovs-vsctl add-br br0 host-1:~$ sudo ovs-vsctl add-br br1 host-1:~$ sudo ovs-vsctl add-port bra eth0 host-1:~$ sudo ifconfig eth0 0 host-1:~$ sudo dhclient br0 host-1:~$ sudo ifconfig br1 10.0.0.1 netmask 255.255.255.0 host-1:~$ sudo ovs-vsctl add-port br1 geneve1 -- set interface \ geneve1 type=geneve options:remote_ip=192.168.203.149
host-2:~$ sudo ovs-vsctl add-br br0 host-2:~$ sudo ovs-vsctl add-br br1 host-2:~$ sudo ovs-vsctl add-port bra eth0 host-2:~$ sudo ifconfig eth0 0 host-2:~$ sudo dhclient br0 host-2:~$ sudo ifconfig br1 10.0.0.2 netmask 255.255.255.0 host-2:~$ sudo ovs-vsctl add-port br1 geneve1 -- set interface \ geneve1 type=geneve options:remote_ip=192.168.203.151
Dissecting Geneve Packets by Wireshark (1)
25
Dissecting Geneve Packets by Wireshark (2)
26
Geneve に関する情報 • 英語
– http://tools.ietf.org/html/draft-gross-geneve-00 – http://cto.vmware.com/geneve-vxlan-network-virtualization-encapsulations/ – http://www.enterprisenetworkingplanet.com/netsp/geneve-generic-network-
virtualization-encapsulation-protocol-advances-video.html – http://searchsdn.techtarget.com/news/2240219051/VMware-Microsoft-end-
encapsulation-protocol-turf-war-with-GENEVE – http://www.plexxi.com/2014/06/attention-overlay-tunnel-construction-ahead
• 日本語 – http://blog.shin.do/2014/05/geneve-encapsulation/ – http://blog.shin.do/2014/07/geneve-on-open-vswitch/
27
Geneve replaces VXLAN / STT / NVGRE ? • Geneve は VXLAN を置き換えるか?
– NO – VXLAN のエコシステムはすでに短時間で置き換えることができないほど大きく成長して
いる – VMware は引き続き VXLAN をサポートし、パートナーと連携をしていく
• Geneve は STT を置き換えるか? – 短期的には NO。長期的には Maybe。 – Geneve が広く受け入れられ、多くの NIC でオフロードができるようになるのが前提
• Geneve は NVGRE を置き換えるか? – 短期的には NO。長期的には Maybe。 – Geneve が Windows に実装され、現在の NVGRE と同程度のエコシステムが形成され
れば・・・
28
トンネルは適材適所
29
http://cto.vmware.com/geneve-vxlan-network-virtualization-encapsulations/ より引用
世の中一筋縄にはいかない^^ • Geneve に反対している人たちもいる!
• 主な主張
– Geneve で実現しようとしていることは、既存の encapsulation (L2TPv3 static tunneling や VXLAN)もしくはそれらの若干の拡張で実現可能!?
– Service Chaining や Metadata を encapsulation と bind すべきではない(Encapsulation 独立であるべき)!?
– VNI が 24bit では不十分!?
30
L2TPv3 static tunneling • L2TP は本来シグナリングを伴うが、L2TPv3 static tunneling はシグナリングを使
わず、両端に静的に設定を設定をすることで L2TPv3 を encapsulation (i.e. Pseudo Wire)として使う方法
• L2TPv3 自体は2005年に RFC (3931) になっており、枯れた仕様。Cisco IOS や Linux の実装あり。
31
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie (optional, maximum 64 bits)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L2TPv3 static tunneling を L2 over L3 encapsulation とみた場合 • Session ID (32bit) が VNI に相当する
• L2TPv3 は IP でも UDP でもトランスポートできるが、マルチパス性を考えると UDP が有利
• より多くのコンテキスト情報(メタデータやService Chaining)は両端に静的に設定し、Session ID で暗黙に表現することになる – したがって 32bit の Session ID を純粋に VNI として使うことはできない
• 厳密には L2TPv3 には規定はないが、L2TPv2 の名残りの「オフセット」フィールドを使い、パケットのどこから TSO をするべきか伝えることは可能かも??
32
VXLAN Generic Protocol Extension (a.k.a. eVXLAN) • Cisco、Huawei、Intel、Microsoftらが提唱
– draft-quinn-vxlan-gpe-03.txt
• VXLAN の拡張 – 複数プロトコルのサポート
• IPv4 (0x01)、IPv6 (0x02)、Ethernet (0x03)、Network Service Header [NSH] (0x04)
– OAM サポート – バージョン
• Cisco ACI で使われている
33
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|R|R|R|I|P|R|O|Ver| Reserved |Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VXLAN Network Identifier (VNI) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VXLAN-gpe を L2 over L3 encapsulation とみた場合 • ほぼ VXLAN と同様の特性
– VNI 長 – マルチパス性 – ハードウェアでの実装のし易さ
• 最大の特徴は NSH ヘッダを使った Service Chaining を可能にすること!
• 拡張性はなし
34
ありがとうございました
35