ネットワーク仮想化 - yuuk1's Digital Garden

# ネットワーク仮想化 ## 定義ネットワーク仮想化(network virtualization)とは、物理ネットワークの機能を「あたかもそこにあるかのように錯覚させる」技術である。ネットワーク仮想化を「異なるユーザー間でネットワークリソースを分割する手段(スライシング)」として説明することが多いが、その本質はスライシングではない。仮想化に関する Popek と Goldberg の 1974 年の記念碑的な論文が定義した「効率的で隔離された複製(efficient, isolated duplicates)」という錯覚こそが本質であり、リソースの分割はその錯覚を実現するための構成要素の一つにすぎない。VL2([[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] が引く Greenberg ら, SIGCOMM 2009)は、この意味でのネットワーク仮想化という用語を導入したおそらく最初の論文であり、「サービスに割り当てられた全サーバだけが、他のサービスから干渉されない一つのイーサネットスイッチで互いに接続されている」という「仮想的なレイヤー2(Virtual Layer 2)」の錯覚を、データセンターの実際の構成(複数サブネットをルータで接続した L3 ネットワーク)の上に作り出す。(Source: ch.5 §5.4) L2ネットワークの仮想化という角度から見ると、VLAN(4096個が上限)ではテナント数が足りない状況に対応するために[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] のPerspective節が説明するVXLAN(Virtual Extensible LAN)が導入された。VXLANは仮想Ethernetフレームを別のEthernetフレームへではなくUDP/IPパケットへカプセル化し、IPネットワークの上で動作するオーバーレイネットワーク(overlay network)を構成する。24ビットのVirtual Network Id(VNI)により、VLANをはるかに超えるテナント数を識別できる。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] Perspective) ネットワーク仮想化は [[ソフトウェア定義ネットワーク]](SDN)を幅広い市場に浸透させた「キラーアプリ」と位置づけられる。Nicira はこのビジョンをサーバ仮想化の成功パターンからの類推で構築し、仮想 L2 スイッチだけでなく仮想 L3 ルーティング・仮想ファイアウォール・仮想ロードバランサーまで、ネットワークのあらゆるレイヤーを完全にソフトウェアで再実装した。基盤となる物理ハードウェアから完全に独立しているため、サーバ仮想化のライブマイグレーション(vMotion)と同様に、ネットワークもマイクロセグメンテーションやゼロトラストネットワーキングといった、物理ネットワークには存在しなかった新しい機能を生み出せる。(Source: ch.5 §5.1, §5.4) ## SDN 最初の商業的成功事例としての動機と位置づけ(ch.2 §2.1) 『Software-Defined Networks: A Systems Approach』第2章は、ネットワーク仮想化を SDN の「最初の広く採用されたユースケース」と位置づけ、その動機をマルチテナントデータセンターの自動化ニーズから説明する。VLAN・VPN といった古くからの仮想化は、部門やラボのようなエンタープライズ内の組織単位を隔離するアドレス空間の分離にとどまり、ファイアウォールポリシーや負荷分散のような高次のネットワークサービスまでは仮想化していなかった。ネットワーク仮想化を SDN によって実現するという発想の原点は Nicira にあるとされ、Teemu Koponen らの NSDI 論文が示した鍵となる洞察は、コントロールプレーンをデータプレーンから分離し論理的に集中させることで、仮想ネットワークの作成・変更・削除を単一の API エントリポイントから行えるようにする、というものだった。これにより、コンピュートやストレージのプロビジョニングに使われていた自動化システム(当時の OpenStack など)が、仮想ネットワークも同様にプログラムから提供できるようになった。(Source: ch.2 §2.1) ネットワーク仮想化の興隆はコンピュート仮想化の興隆に数年遅れて起き、かつそれに強く後押しされた点も、動機の理解に欠かせない。コンピュート仮想化がサーバの手作業プロビジョニングを過去のものにし、ネットワーク設定という手作業かつ時間のかかる工程を、クラウドサービス提供における「長い一本の棒(long pole)」として露呈させた。さらに、仮想マシンのライブマイグレーション(実行中の VM が IP アドレスを保持したままネットワーク上の位置を移動できる機能)が、手作業によるネットワーク設定の限界をいっそう際立たせた。この自動化の必要性は当初、大規模クラウド事業者において最初に認識され、その後エンタープライズのデータセンターにも波及して主流になっていった。すなわち本ページが定義する「効率的で隔離された複製」という仮想化の錯覚は、単独の技術的理想としてではなく、「仮想ネットワークを物理ネットワークの構成作業から切り離し、コンピュート・ストレージと同じ速度でプログラム的に生成・破棄できるようにする」という、コンピュート仮想化の成功パターンをネットワークへ輸入する動機から生まれた。(Source: ch.2 §2.1) ## 実装アーキテクチャ:三プレーンと分散サービス、そして「これはSDNか」(ch.8) 『Software-Defined Networks: A Systems Approach』第8章は、ネットワーク仮想化システムの一般アーキテクチャを、管理・制御・データという三プレーンに分解して説明する。管理プレーンは北向き API 要求を「希望状態(desired state)」として蓄積し、データプレーン(仮想スイッチの集合)は VM の位置などの「発見状態(discovered state)」を報告し、制御プレーンは両者を継続的に突き合わせて必要な制御指令を計算する。このアーキテクチャは第3章が示す汎用 SDN アーキテクチャ(分散データプレーンの上に集中コントローラが乗る構図)と素直に対応しており、Nicira チームが構築した初期のネットワーク OS Onix は [[ONOS]] の先駆けと位置づけられる。(Source: ch.8 §8.2.2) ネットワーク仮想化が提供する機能(ファイアウォール・ロードバランサー・ルーティング等)は、集中した箱としてではなく各ホストの仮想スイッチへ分散配置される「分散サービス」として実装される。従来型の集中ファイアウォールは、同一ホスト上の VM 間通信すら外部のファイアウォールへ迂回させる(ヘアピン化)非効率とボトルネックを生むのに対し、分散ファイアウォールは各仮想スイッチでファイアウォール処理を行い、ホストを跨がない通信はホスト内で完結させる。この分散配置が、通信可否をきめ細かく規定するマイクロセグメンテーションという新しいセキュリティモデルを可能にした。(Source: ch.8 §8.2.3, §8.5) 構成要素としては、仮想ネットワークのアドレス空間を物理ネットワークから切り離すカプセル化(VXLAN の限界を克服した [[GENEVE]])、データプレーンの中心である仮想スイッチ(最も広く使われるのは [[Open vSwitch (OVS)]])、および性能最適化(DPDK・SR-IOV・SmartNIC オフロード)がある。実例システムである [[OVN]] は、OVS を土台に、Northbound/Southbound の2つのデータベースと集中/分散ハイブリッドな制御プレーンを組み合わせる。(Source: ch.8 §8.3, §8.4) 第8章はさらに「ネットワーク仮想化は本当に SDN か」という問いに正面から答える。物理ネットワークを変えないという批判に対し、著者らは制御/データプレーンの分離と集中コントローラ、そして OVS に代表される完全にプログラム可能な転送プレーンという中核原則への忠実さを論拠に、ネットワーク仮想化を SDN の一領域(ドメイン)として位置づける。SDN には普遍性の要求が無く、データセンターアンダーレイとネットワーク仮想化オーバーレイという2つのドメインが、互いを意識せず同じデータセンターに共存しうるという整理を示す。(Source: ch.8 §8.6) ## レイヤリングによる資源共有すなわち「スライシング」(ch.4 §4.4) 『The Real Internet Architecture』第4章は、レイヤリングが使われる4つの目的の1つとして「資源共有すなわちスライシング」を位置づける。これは複数のオーバーレイが単一のアンダーレイの上にレイヤリングされ、オーバーレイがアンダーレイの資源を共有し、アンダーレイが資源を各オーバーレイへ配分するために「スライス」するパターンである。最も普遍的な例は、すべてのインターネットベースのアプリケーションネットワーク・分散システムがbase Internetの資源を共有していることである。(Source: ch.4 §4.4) - クラウドコンピューティングにおけるテナントネットワークは、通常データセンターネットワークに潤沢な容量を用意することで、個々のテナントの帯域使用量を厳密に監視・制御しない運用になる。これに対しVirtual Network Infrastructure(VINI、多数の実験用IPネットワークがレイヤリングされる広域網)は、同時実行される実験がVINIの容量を食い潰しうる上、実験の妥当性に孤立した資源が要求されるため、実験用オーバーレイへの帯域割り当てを明示的に行う必要がある。すなわち「スライシング」という同じパターンでも、アンダーレイの資源制約の有無によって、暗黙の潤沢な共有と明示的な資源割り当てという異なる運用が生じる。(Source: ch.4 §4.4) - 新標準ネットワーク(SCION・IPvN)を旧IPネットワークと同一の物理インフラ上で共存させる際にも、スライシングパターンが使われる——SCIONの安全性・性能保証は、パケットが実際に旧IPネットワーク上で運ばれているなら無効になりうるため、独立にスライスされた資源を保証する必要がある(§4.8.1.2)。(Source: ch.4 §4.4, §4.8.1.2) ## 横断的知見 - **本ページが「ネットワーク仮想化の本質はスライシングではない」と定義する一方(Popek-Goldberg的な「効率的で隔離された複製」こそが本質)、RIA第4章は「資源共有すなわちスライシング」をレイヤリングの4目的の1つとして独立に定義しており、両者は「スライシング」という同じ語に異なる位置づけを与えている**: 本ページの既存の定義は、VL2論文の「仮想的なレイヤー2」の錯覚こそがネットワーク仮想化の本質であり、リソース分割(スライシング)はその錯覚を実現する構成要素の一つにすぎないと明言する(ch.5 §5.4)。これに対しRIA第4章§4.4は「スライシング」を、複数オーバーレイが単一アンダーレイの資源を共有するというレイヤリングの目的別パターンの1つとして、独立した第一級の概念に位置づける——RIAにとってスライシングは「仮想化の錯覚を実現する手段」ではなく「レイヤリングが持つ4つの目的のうちの1つ」である。両者は矛盾しないが、LambdaNote第5章がスライシングを仮想化という上位概念に従属させて論じるのに対し、RIA第4章はスライシングを仮想化とは独立した目的として並列に扱っており、「スライシングは何に従属する概念か」という位置づけそのものが文献によって異なる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] §5.4, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 4 The Real Internet Architecture]] §4.4) - **VINIの明示的な帯域割り当てとNiciraのソフトウェア定義な仮想化は、どちらも「隔離」を目標にしながら、隔離の実現手段が対照的である**: 本ページが記録するNicira/NSXのネットワーク仮想化は、物理ハードウェアから完全に独立したソフトウェアの再実装によって隔離を実現する(ch.5)。RIA第4章が示すVINIの隔離は、物理マシン・リンクを共有しつつ各メンバーにCPU時間の制御されたシェアを与えるという、資源割り当てレベルでの隔離である。前者はソフトウェアの独立性による論理的隔離、後者は資源配分の制御による物理的隔離であり、「隔離された複製」という同じ目標(Popek-Goldberg)への異なる到達経路を示す。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] §5.1, §5.4, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 4 The Real Internet Architecture]] §4.4) - **ネットワーク仮想化はソフトウェアへの引き剥がしと、専用ハードウェアへの再オフロードという往復運動を見せる**: ch.5 は仮想スイッチを含むネットワーク仮想化のあらゆるレイヤー(仮想 L2 スイッチ・仮想 L3 ルーティング・仮想ファイアウォール・仮想ロードバランサー)が完全にソフトウェアで実装される点を強調する(§5.1, §5.4)。一方 ch.10 は、その同じ仮想スイッチが今度は IPU/DPU という専用ハードウェアへオフロードされる対象になると位置づける。仮想スイッチ全体を移動するにはオフロードエンジンが完全にプログラム可能である必要があり、一部機能しか移せなければ残りの CPU 処理がボトルネックとして残るという教訓が、Nicira・VMware NSX チームの経験から導かれている。つまりネットワーク仮想化は「専用ハードウェアからソフトウェアへ」機能を引き剥がした技術であると同時に、その後「ソフトウェアから(新世代の専用)ハードウェアへ」再び移される対象にもなるという往復運動を辿っている。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 10 SmartNIC、IPU、DPU]]) - **本ページが定義する「効率的で隔離された複製」という錯覚は、データセンターのL2/L3スイッチングという当初の適用範囲を越え、RANの無線リソース分離(ネットワークスライシング)にも及ぶが、成熟度には大きな差がある**: ch.5 はVL2・Nicira・NSXという、データセンター内で実装が確立し公開情報でも比較可能な事例からネットワーク仮想化の定義を導いていた。[[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 9 5G：対照的なアーキテクチャ]] §9.3が描くネットワークスライシングは、異なるクラスのトラフィックを互いに分離し各スライスが独自のキューを持つという点で、まさに無線リソースという物理的制約の強い領域における「隔離された複製」の試みである。しかし本章はこれを「確約されたものではなく願望に近い」と明記しており、ch.5が描くデータセンターのネットワーク仮想化ほど実装が成熟していない。ネットワーク仮想化という概念の適用範囲が、実装が確立した領域(データセンターのL2/L3)から、まだ実証段階の領域(RANの無線リソース)へと広がりつつある途上にあることを示す。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.4, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 9 5G：対照的なアーキテクチャ]] §9.3) - **MPLS ベースの VPN は、本ページが定義する「効率的で隔離された複製」という錯覚を、SDN 以前の世代の技術でどこまで実現していたかを示す先行事例である**: 本ページは Popek-Goldberg 的な「効率的で隔離された複製」という錯覚こそがネットワーク仮想化の本質であり、VL2・Nicira・NSX がデータセンター内でこれをソフトウェアで実装したと定義する。[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] §4.4.3 が説明するレイヤ3 MPLS VPN は、SDN 以前から同じ「錯覚」——単一の物理ネットワークを複数顧客に独立した仮想 IP ネットワークとして見せ、顧客 A は顧客 B の存在を意識しない——を、ラベルスタックによるトンネルと BGP による経路配布という手段で実現していた。両者を比較すると、ネットワーク仮想化という目的自体は SDN 登場以前から追求されており、SDN(Nicira/NSX)が変えたのは目的ではなく手段(専用プロトコルスタック中心の実装から、汎用サーバ上のソフトウェアによる実装への移行)であることが分かる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.1, §5.4, [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] §4.4.3) - **MPLS VPN の隔離単位は「顧客ごとの仮想 IP ネットワーク」だが、その設定はプロバイダ側で BGP を介して行われる点が、Nicira 以降のソフトウェア定義な仮想化との構造的な違いである**: 教科書第4章は MPLS レイヤ3 VPN の構成を「サービスプロバイダがBGPを用いてトンネルの構成を自動化する」と説明し、顧客はプロバイダに設定を委ねる。これは Nicira/NSX が目指した「テナント(仮想ネットワークの利用者)自身がソフトウェアで仮想ネットワークを制御する」というセルフサービス的なモデルと対照的であり、隔離の実現主体(プロバイダ中心か、テナント中心か)という軸でも両者は異なる設計思想を持つ。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] §4.4.3, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.4) - **VXLAN(ch3)とMPLSレイヤ3 VPN(ch4)は、本ページが定義する「効率的で隔離された複製」という錯覚を、いずれもカプセル化によるトンネルで実現する点で共通するが、カプセル化する層と隔離の対象が異なる**: 本ページの既存の横断的知見は、MPLS VPNがラベルスタックによるトンネルとBGPによる経路配布で「顧客ごとの仮想IPネットワーク」という隔離を実現していたと記録する(ch4 §4.4.3)。[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] のPerspective節が説明するVXLANは、これとは異なる層を隔離の対象にする——MPLS VPNがIP(L3)ネットワークそのものを顧客ごとに仮想化するのに対し、VXLANは仮想Ethernetフレーム(L2)をUDP/IPパケットにカプセル化することで、L2ネットワークをIPネットワークの上のオーバーレイとして仮想化する。VXLANの24ビットVirtual Network Id(VNI)は、本ページが記録するVLANの4096個という上限を克服するために導入された識別子であり、VLANの中にVXLANをカプセル化し、さらにその中にVLANをカプセル化するという入れ子構造すら許す。著者はこれを「仮想ネットワークがどこまでも入れ子になる(virtual networks all the way down)」と表現し、カプセル化こそが仮想化の礎石であるという、本ページのPopek-Goldberg的定義(「効率的で隔離された複製」)と同じ結論に、L2オーバーレイという異なる出発点から到達している。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] Perspective, [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] §4.4.3) - **RIA第3章は、本ページが「効率的で隔離された複製」という錯覚として説明するVXLANを、レイヤリング演算子の厳密な定義に基づく実装の内部構造(実装送信/受信テーブル、ルックアップテーブルによるディレクトリ)まで踏み込んで具体化する**: 本ページの既存の知見は、VXLANを「仮想ネットワークがどこまでも入れ子になる」というカプセル化の原理から説明してきた(Systems Approach ch.3 Perspective)。RIA第3章§3.4.5.3-4は同じVXLANを、テナントEthernet(オーバーレイ)のリンクがデータセンターIPネットワーク(アンダーレイ)のUDPセッションによって実装されるという[[レイヤリング]]の定義の具体例として説明し、W→Xの最初の通信を例に、ルックアップテーブルがルーティングテーブルとディレクトリの両方の役割を兼ねる様子や、実装送信テーブル・実装受信テーブルという状態管理の内部構造まで示す。仮想化概念が「錯覚として何を達成するか」を語るのに対し、RIAは「その錯覚を生む状態遷移がどう起きるか」を語っており、両者は同じVXLANという技術の異なる解像度の説明として補完関係にある。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] Perspective, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.4.5.3, §3.4.5.4) - **ネットワーク仮想化という語の「起源」を語る 2 つの物語が、異なる技術系譜を指している**: 本ページの既存の知見は VL2([[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] が引く Greenberg ら, SIGCOMM 2009)を「この意味でのネットワーク仮想化という用語を導入したおそらく最初の論文」と記録していた。これに対し[[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]]は「SDN を使って仮想ネットワークを作るという発想の原点」を Nicira の Teemu Koponen らによる NSDI 論文(2014年)に帰する。両者は矛盾する主張ではなく、異なる問いに答えている——VL2 は「仮想的なレイヤー2」という**用語・抽象化**の初出を、Nicira の NSDI 論文は「SDN(コントロールプレーンの分離と集中化)を仮想ネットワーク作成の実現手段として使う」という**手段・実装アプローチ**の起源を語る。ネットワーク仮想化には「何を実現するか(抽象化としての仮想 L2)」と「どう実現するか(SDN による集中制御)」という 2 本の系譜があり、単一の起源に一本化できない。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] §5.4, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]] §2.1) - **「ネットワーク仮想化は本当に SDN か」という懐疑を、SDN の主著自身が正面から認めている**: 本ページの既存の知見は Nicira/NSX のネットワーク仮想化がソフトウェアによる完全な再実装によって隔離を実現すると記録してきたが、その実装がどこまで SDN の理想(ネットワークの分解、disaggregation)に忠実かは論じていなかった。[[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]]は、オリジナルの Nicira プラットフォームがコントローラ・データプレーン間通信に OpenFlow を用いた点で SDN の性質を体現する一方、実際のコントローラとスイッチの結合はプロプライエタリなシグナリングによる密結合であり、SDN が志向した「ネットワークの分解」を実現してはいないと明言する。SDN の教科書自身がこの緊張関係を「根強い論争(reasonable debates)」として明示的に認めていることは、ネットワーク仮想化を SDN の成功事例として無条件に扱うことへの留保として重要である。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]] §2.1) - **ネットワーク仮想化における性能オーバーヘッドの定量比較が、ハードウェア仮想化の知見と同型の教訓を示す**: 未解決の問いは、ハードウェア仮想化(Middleware '21)で観測された「実装の成熟度がオーバーヘッドを左右する」という定量的傾向が、ネットワーク仮想化でも同様に見られるかを尋ねていた。第8章§8.3.3は直接この比較を与えるものではないが、関連する定量データを示す——OVS 単体の転送レートが毎秒約100万パケット(1Mpps)にとどまるのに対し、DPDK を適用した OVS-DPDK は毎秒1600万パケット(16Mpps)以上を達成する(RedHat Developer の実測、Virtual-to-Physical Gateway 用途)。これはハードウェア仮想化の「実装の成熟度」という軸そのものとは異なるが、「同じ抽象化(仮想スイッチ)でも実装上の最適化選択(DPDK の有無)によってオーバーヘッドが1桁以上変わる」という同型の教訓を示す。両ドメインとも、仮想化という抽象化そのものの本質的コストではなく、個々の実装判断がオーバーヘッドの大半を決定するという点で一致する。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 8 Network Virtualization]] ch.8 §8.3.3, [[@2021__Middleware__A Fresh Look at the Architecture and Performance of Contemporary Isolation Platforms]] Conclusion 2) - **VMware NSX が「物理ネットワーク機器のインターフェースに触れずに実現する」とされていたネットワーク仮想化の技術的な仕組みが、第8章の三プレーンアーキテクチャによって具体化された**: 未解決の問いは、ch.5 §5.2 が概要のみ述べていた NSX の実現方法が、本ページの定義する「効率的で隔離された複製」とどう技術的に対応するかを尋ねていた。第8章§8.2.2が示す一般アーキテクチャ(管理プレーンが API 要求を希望状態として蓄積し、データプレーンの仮想スイッチが発見状態を報告し、制御プレーンが両者を継続的に一致させる)は、物理ネットワーク機器のコントロールプレーン/データプレーンインターフェースを一切変更せず、サーバ側の仮想スイッチだけを操作して仮想ネットワークを実現する仕組みを説明しており、NSX のようなシステムが「物理機器に触れない」仮想化をどう実現するかへの一般的な回答を与える。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 8 Network Virtualization]] ch.8 §8.2.2, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.2) - **OVN の CMS 統合が、ch.3 Perspective が指摘していた「仮想ネットワークの自動化には改善の余地がある」という課題への一つの回答を示すが、完全な解消ではない**: 未解決の問いは、Nicira/NSX のソフトウェア主導ネットワーク仮想化(ch.5)がこの自動化課題にどこまで答えているかを、ch.3 が Tungsten Fabric 等の OSS 名を挙げるにとどまり検証していなかった点を指摘していた。第8章§8.4が説明する OVN は、OpenStack や Kubernetes のような Cloud Management System(CMS)と、OVN/CMS プラグイン・Northbound DB(希望状態)・logically centralized な `ovn-northd`・各ハイパーバイザーの OVN コントローラという具体的な自動化パイプラインを示し、仮想ネットワークの作成・変更を単一の API エントリポイントから行える仕組みを技術的に裏付ける。ただし OVN の説明は VM/コンテナの作成・接続の自動化にとどまり、移行(マイグレーション)やネットワーク削除に伴う後始末をどこまで自動化がカバーするかは明示されておらず、ch.3 が指摘した「改善の余地」が完全に解消されたとは言えない。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 8 Network Virtualization]] ch.8 §8.4, [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] Perspective) - **ch.2 が要約していた「コンピュート仮想化の成功パターンをネットワークへ輸入する」という動機の連鎖が、第8章§8.1でより詳細に裏付けられた**: 未解決の問いは、ch.2 §2.1が述べる動機の連鎖(手作業プロビジョニングの排除 → ライブマイグレーションによる限界露呈 → ネットワーク自動化の必要性)の因果の強さを、第8章が検証してくれるかを尋ねていた。第8章§8.1は同じ連鎖をより具体的に描く——VM プロビジョニングがソフトウェアだけで完結するようになり日から分・秒に短縮されたことで、ネットワーク設定が「長い一本の棒」であることが露呈したという記述、および VM のライブマイグレーションが IP アドレスの物理サブネットへの拘束という具体的な技術的課題(サブネット移動の制約か IP アドレス変更による接続断のどちらかを強いる)を生み、これが VL2 という具体的な解決策を生んだという記述である。VL2 を「ネットワーク仮想化の第一歩」と位置づける点で ch.2・ch.8 は一致しており、動機の連鎖は ch.2 の要約よりも技術的な解像度で裏付けられたと言える。ただし「コンピュート仮想化がなければネットワーク仮想化は生まれなかったか」という反実仮想の強さそのものは、依然としてどちらの章も直接には論じていない。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 8 Network Virtualization]] ch.8 §8.1, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]] §2.1) - **第8章の脚注が、第10章(LambdaNote)の IPU/DPU オフロード条件(完全なプログラム可能性)を独立の文脈から裏付ける**: 本ページの既存の横断的知見は、LambdaNote 第10章が Nicira/VMware NSX チームの教訓として「オフロードエンジンは完全にプログラム可能である必要がある」と述べていたことを記録していた。*Software-Defined Networks: A Systems Approach* 第8章§8.3.3の脚注は、これとは独立に P4 が SmartNIC をプログラムする手段として台頭しつつあることに触れ、「vSwitch・SmartNIC・ベアメタルスイッチのいずれで実装されたデータプレーンであっても、その能力を制御プレーンへ公開する方法が収束していく可能性」を示唆する。SmartNIC への部分オフロードが実用的であるためには、対象データプレーンを P4 のような共通言語で記述できるだけの汎用性が必要だという点で、両者は異なる書籍・異なる章から同じ結論(十分なプログラム可能性が前提条件)に到達している。ただしこれは「仮想化の錯覚の質が保たれるか」という未解決の問いそのものへの回答ではなく、オフロードの前提条件についての独立した裏付けにとどまる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 8 Network Virtualization]] ch.8 §8.3.3, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 10 SmartNIC、IPU、DPU]] ch.10 §10.2) - **RFC 7348(VXLAN 本体)を一次資料として読むと、本ページが二次資料(Systems Approach ch.3 Perspective、RIA第3章)から積み重ねてきた VXLAN の要約——「仮想 Ethernet フレームを UDP/IP パケットへカプセル化」「24 bit VNI」——が、単なる要約以上に精密な動機付けを持つことが分かる**: 本ページはこれまで VXLAN を「VLAN の 4096 個という上限に対応するために導入された」技術として記録してきた(ch3 Perspective)。RFC 7348 §3 を直接読むと、この動機は実際には STP/マルチパスの制約(§3.1)・マルチテナント隔離要件(§3.2)・ToR スイッチのテーブルサイズ不足(§3.3)という 3 つの独立した構造的問題に分解されており、単一の「VLAN 上限問題」への対応という説明は簡略化だったことが分かる。特に ToR テーブルサイズ問題(仮想化により ToR が個々の VM の MAC アドレスを学習する必要が生じ、テーブル溢れがフラッディングを招く)は、本ページのこれまでの記述には現れていなかった動機であり、[[データセンターL2ファブリック]] が扱う PortLand の PMAC(擬似 MAC)設計とも接続する論点である。また RFC は VTEP がステートレスにカプセル化を行い、データプレーン学習(内側送信元 MAC → 外側送信元 VTEP IP)により通信相手のマッピングを学習するという制御プレーンの詳細を、二次資料よりも精密に記述する。(Source: [[@2014__RFC__Virtual eXtensible Local Area Network (VXLAN) - A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks]] §3, §4) - **RFC 8365(EVPN の NVO 転用仕様)は、本ページが Nicira/NSX から積み重ねてきた「集中コントローラによるソフトウェア定義な仮想化」とは異なる、BGP による分散制御プレーンという第2の NVO 実現経路を示す**: 本ページのこれまでの知見は、RFC 7364 が定義する NVO 要件(テナント隔離・大規模テナント収容・L2 接続の拡張・VM モビリティ)を、Nicira/NSX の完全ソフトウェア再実装と第8章の三プレーンアーキテクチャ(管理・制御・データプレーンの分離、集中コントローラ)から説明してきた。[[@2018__IETF__A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)]] は同じ NVO 要件に対し、[[EVPN]](RFC 7432)という MPLS/BGP VPN 系譜の分散型 BGP 制御プレーンを VXLAN・NVGRE・MPLS over GRE の上に載せることで応える——Route Reflector・BGP Encapsulation Extended Community・mass withdrawal といった BGP ネイティブの機構がスケーラビリティを担い、Nicira/NSX のような論理的に集中したコントローラは登場しない。同じ NVO という目的に対し、「集中コントローラ + ソフトウェア再実装」(Nicira/NSX/OVN 系)と「分散 BGP 制御プレーン」(EVPN 系)という設計思想が全く異なる2つの実現経路として並立していることを、本ページは初めて記録する。(Source: [[@2018__IETF__A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)]] §1, §4) - **Nicira の NSDI 論文(Koponen et al., 2014)を一次資料として読むと、「コントロールプレーンの分離と集中化」という二次資料の要約が、実際には宣言的言語 nlog による増分状態計算と論理/物理二層のコントローラクラスタという、はるかに具体的な設計に支えられていたことが分かる**: 本ページの既存の知見は、[[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]] §2.1 が要約する「コントロールプレーンをデータプレーンから分離し論理的に集中させることで、仮想ネットワークの作成・変更・削除を単一の API エントリポイントから行えるようにする」という Koponen らの鍵となる洞察を、論文自体を読まずに記録していた(未解決の問いとして明記)。[[@2014__NSDI__Network Virtualization in Multi-tenant Datacenters]] を読むと、この「論理的な集中」は単一の集中コントローラではなく、論理コントローラ層(O(N) の計算複雑度で論理データパスをシャーディング)と物理コントローラ層(トランスポートノードごとの詳細化を O(N^2) で処理)という二層構造によって実現されており、かつ状態計算そのものは宣言的な Datalog ベース言語 nlog(約1200 declaration・900テーブル)による増分計算によって、イベント順序に依存しない正しさを確保していることが分かる。「コントロールプレーンの分離と集中化」という二次資料の要約は正確だが、その実現手段(宣言的増分計算・二層シャーディング)は二次資料には現れていなかった技術的詳細である。(Source: [[@2014__NSDI__Network Virtualization in Multi-tenant Datacenters]] §4.3, §5.1) - **論文が自ら報告する限界(OpenFlow採用によるO(N^2)の物理層スケーリング、非トランザクショナルな一時的状態不整合)は、本ページが第8章から記録してきた「これはSDNか」という懐疑と、異なる角度から同じ緊張関係を裏付ける**: 本ページの既存の知見は、[[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]] が「オリジナルの Nicira プラットフォームはコントローラ・スイッチ間がプロプライエタリなシグナリングで密結合しており、SDN が志向する『ネットワークの分解』を実現していない」と批判していたことを記録していた。NVP 論文自身の Discussion(§8)は、この批判とは別の角度から限界を認めている——OpenFlow の採用が「物理コントローラ層のスケーリングにおける大きな複雑要因」になり、論理層の O(N) に対し物理層は O(N^2) の操作を要求される。また OpenFlow の非トランザクショナルな性質が、コントローラのクラッシュ時にスイッチが不整合な状態のまま動作するという一時的な問題を生み、次世代 NVP では宣言的計算・通信チャネル全体をトランザクショナル化する必要が生じた。二次資料が指摘する「密結合」という設計批判と、一次資料が自認する「O(N^2)スケーリング」「非トランザクショナルな不整合」という具体的な技術的負債は、いずれも OpenFlow という基盤プロトコルの選択に起因する点で符合する。(Source: [[@2014__NSDI__Network Virtualization in Multi-tenant Datacenters]] §8.2) ## 未解決の問い - ネットワーク仮想化が生み出した「独自の物理法則」(Martin Casado の表現、ch.5 §5.4)という比喩は、具体的にどのような新機能(マイクロセグメンテーション、ゼロトラストネットワーキング以外)を指すのか。本章はこれ以上の列挙をしていない。第8章はマイクロセグメンテーションの技術的詳細を掘り下げたが、それ以外の「新しい物理法則」の具体例は追加していない。 - AWS VPC が「少なくとも仮想ネットワークの一種」(ch.5 §5.4)とされるが、Nicira・Google・Azure の実装が公開情報で比較可能なのに対し AWS の実装詳細は入手困難だと著者自身が明言している。この非対称性は、ネットワーク仮想化の実装アプローチの多様性をどこまで覆い隠しているか。 - 第10章が描く IPU/DPU への仮想スイッチオフロードは、本ページの Popek-Goldberg 的「効率的で隔離された複製」という定義とどう両立するか。オフロード先が専用チップになっても仮想化の「錯覚」の質(効率性・隔離性)は保たれるのか、それとも新しい種類のオーバーヘッドや隔離漏れが生じうるのか。ch.10 はオフロードを可能にする条件(完全なプログラム可能性)を論じ、ch.8 §8.3.3もP4によるデータプレーン記述の収束という形で独立に同じ前提条件を裏付けたが、仮想化の錯覚そのものへの影響にはどちらも踏み込んでいない。 - ネットワークスライシングが「願望」の段階から実運用段階へ移行した場合、本ページが定義する「効率的で隔離された複製」という基準(効率性・隔離性)をどこまで満たせるか。無線リソースは有線のL2/L3スイッチングと異なり物理的に共有・競合する資源であるため、データセンターのネットワーク仮想化と同水準の隔離を実現できるかは、ch.9 の記述だけでは判断できない。 - RIA第3章が示すVXLANの実装(ルックアップテーブル、実装送信/受信テーブル)は、単一のデータセンター内という前提で説明される。マルチデータセンター・マルチクラウドにテナントネットワークを拡張する場合、この「ルックアップテーブル1つがルーティングとディレクトリを兼ねる」という設計はどこまでスケールするか。RIA第3章はデータセンター内部の説明にとどまり、この問いには答えていない。第8章のOVNもNorthbound/Southbound DBの説明を単一データセンター内の文脈にとどめており、この問いには答えていない。 - RIA第4章がスライシングをレイヤリングの独立した目的として扱う一方、本ページはスライシングを仮想化の錯覚を実現する構成要素として従属させて扱う。この位置づけの違いは、単なる強調点の違いなのか、それとも「仮想化」と「スライシング」という2つの語が指す対象範囲そのものが文献によって異なるのか(仮想化はスライシングを含む上位概念か、それとも重なりを持つ別概念か)は、本wikiではまだ判定できない。 - 第8章§8.6は、ネットワーク仮想化がSDNの中核原則(制御/データプレーン分離、集中制御、プログラマブルな転送プレーン)に忠実であると論じるが、ch.2が指摘していた「Niciraのオリジナルプラットフォームはコントローラ・スイッチ間がプロプライエタリなシグナリングで密結合しており、SDNが志向する『ネットワークの分解』を実現していない」という批判には直接答えていない。§8.6の擁護論(中核原則への忠実さ)は、ch.2が指摘したこの具体的な結合方式の問題を解消したのか、それとも単に異なる評価基準(原則の遵守)にすり替えているだけなのかは、本wikiではまだ判定できない。 - §8.6はデータセンターアンダーレイ(リーフスパインファブリック)とネットワーク仮想化オーバーレイが「互いの存在を意識せず」同じデータセンターに同時配備されると述べ、将来的に共有ネットワーク OS・共通転送記述言語・共通ツールチェーンへ収束するかもしれないと推測する。この推測を裏付ける実例(共有 Network OS 上でアンダーレイ制御アプリとオーバーレイ制御アプリが共存する事例など)は、本wikiにはまだ無い。第7章のSD-FabricはONOS上で動くアンダーレイ制御アプリだが、オーバーレイ側(OVN等)との統合事例は本章では触れられていない。 - Nicira/NSX 系(集中コントローラ)と EVPN 系(分散 BGP)という2つの NVO 実現経路を直接比較した文献は、本 wiki にはまだない。両者は運用時のスケーラビリティ・障害収束時間・マルチベンダー相互運用性(EVPN は標準化された BGP、NSX は単一ベンダーのコントローラ実装)のどの軸で優劣が分かれるのか、あるいは異なる適用領域(EVPN はサービスプロバイダ由来でキャリア・大規模データセンター向け、NSX はエンタープライズ・クラウドデータセンター向け)ゆえに直接比較が成立しないのかは未確認。 ## 関連 - 概念: [[ソフトウェア定義ネットワーク]] / [[データセンターネットワークトポロジ]] / [[ハードウェア仮想化]] / [[コンテナ仮想化]] / [[スマートNICオフロード]] / [[5Gモバイルネットワーク]] / [[MPLS]] / [[レイヤリング]] / [[オーバーレイネットワーク]] / [[EVPN]] - 実体: [[Nicira]] / [[Martin Casado]] / [[Bruce Davie]] / [[VMware]] / [[ONOS]] / [[Open vSwitch (OVS)]] / [[OVN]] / [[GENEVE]] / [[VXLAN]] / [[Onix]] / [[Network Virtualization Platform (NVP)]] / [[Teemu Koponen]] - 関連 MOC: [[Network - MOC]] - [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] — VXLANによるL2オーバーレイネットワークの教科書的説明(Perspective節)。 - [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] — VXLANをレイヤリング演算子の実装として説明する形式的モデル(§3.4.5)。 - [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 4 The Real Internet Architecture]] — スライシングをレイヤリングの独立した目的として位置づける形式的モデル(§4.4)。 - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]] — SDN最初の商業的成功事例としての位置づけ、マルチテナントデータセンターの動機、Nicira/NSDI論文への言及(§2.1)。 - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 8 Network Virtualization]] — 三プレーンアーキテクチャ・分散ファイアウォール・GENEVE・OVS・OVN・マイクロセグメンテーション・「これはSDNか」という位置づけの詳述。 - [[@2014__NSDI__Network Virtualization in Multi-tenant Datacenters]] — NVPの設計・実装・評価を報告する一次資料。nlogによる宣言的増分計算、論理/物理二層コントローラクラスタ、STTカプセル化の詳細。 ## 出典 - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]](ネットワーク仮想化の定義、VL2、Nicira の実装、NSX、AWS VPC への言及) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 9 5G：対照的なアーキテクチャ]](ネットワークスライシングとRANの無線リソース分離、§9.3) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 10 SmartNIC、IPU、DPU]](仮想スイッチがIPU/DPUへのオフロード対象候補になる文脈、図10.2) - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 4: Advanced Internetworking, §4.4.3. https://book.systemsapproach.org/scaling.html - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 3: Internetworking, Perspective: Virtual Networks All the Way Down. https://book.systemsapproach.org/internetworking.html - Pamela Zave, Jennifer Rexford, *The Real Internet Architecture*, Princeton University Press, 2024, Chapter 3, §3.4.5; Chapter 4, §4.4. - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 2: Use Cases, §2.1. https://sdn.systemsapproach.org/uses.html - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 8: Network Virtualization. https://sdn.systemsapproach.org/netvirt.html - Mahalingam, M., et al., "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August 2014. https://www.rfc-editor.org/rfc/rfc7348.html - [[@2018__IETF__A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)]](RFC 8365 §1, §4) - [[@2014__NSDI__Network Virtualization in Multi-tenant Datacenters]](NVPの設計・実装・評価、§2, §4, §5, §8)