tun / tap vs bridge + vnet vs macvtapの違いは何ですか？（仮想化KVMの場合）

KVMネットワーキングを行うためのさまざまな方法を見つけました。しかし、私はそれを行うための正しい方法は何かにこだわっています。openstackがmacvtapを使用してneutronネットワーキングを行うことを発見しました。そしてそれはよさそうだ。

しかし、違いは何であり、それぞれの方法を使用する理由は何ですか。

方法1 [古い？TUN / TAP]

http://www.shakthimaan.com/installs/debian-tun-tap-setup.html

/--------\   /----\   /----\   /----\   /--------\
|Internet|---|eth0|---|br0 |---|tap0|---|Guest NIC
\--------/   \----/   \----/   \----/   \--------/

非推奨ですよね？

方法2 [Bridge + Vnet] <-それがvirt-managerのすることです

http://www.linux-kvm.com/content/using-bridged-networking-virt-manager

基本的に、物理インターフェイスを内部に持つブリッジインターフェイスを作成し、

auto br0
#iface br0 inet dhcp
iface br0 inet static
address 172.16.0.100
network 172.16.0.0
netmask 255.255.0.0
broadcast 172.16.255.255
gateway 172.16.0.1
   bridge_ports eth2
   bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

また、virt-managerから仮想マシンを起動すると、vnetインターフェースが作成され、ブリッジに追加されます。少なくとも私の知るところまで。tun / tapインターフェイスは必要ありません。

それは長い間非常にうまく機能しましたが、今では生意気で私は問題を見つけました。

https://bugs.launchpad.net/ubuntu/+source/core-network/+bug/1255516

TAPインターフェイスなしで新しいvnetインターフェイスをブリッジに追加できるのはなぜですか？

方法3 [MACVTAP]

最後はmacvtapインターフェースです。

http://virt.kernelnewbies.org/MacVTap

TUN / TAPソフトウェアインターフェイスをコピーしますが、より良い方法で行います。どのようにすればよいのかわかりませんが、より良いようです。

2番目の方法に対するmacvtapの利点は何ですか？

何がいいですか？

これに関する助けはありますか？

本当に何を達成したいかによって異なります

• TAP / TUN

VMでも物理マシンでも構いません。TUNはトンネル化されたネットワークをもたらし、デバイスをTAPします。つまり、トンネル化されたネットワークを経由して別のネットワークに到達します。

たとえば、OpenVPNネットワークを構成すると、クライアントに10.8.0.6が与えられます。VPNサーバー10.8.0.1は、リクエストを背後の別のネットワーク（192.168.xxなど）にルーティングします。TAPを使用する場合、ターゲットネットワーク（192.168.10.x / 24）から直接IP（192.168.10.10/24）を受け取ります。シンプル。

• ブリッジ

「Linux Bridge」は、VNET（VMから）を物理イーサネットにブリッジします。VM（KVMベース）が必要な場合、ホスト上のvnetとイーサネット間のブリッジは必須です

ユースケースに依存すると思います。

仮想ホストの自動追加/削除？

macvtapを試してみてください。べき macvtap直接タップキャラクタデバイスを何らかの方法でネットワークスタックをバイパスし、輸出としても、performanter macvlan（おおよそ物理デバイスに別のMACを追加するように、そこに到着に関する情報をネットワークスタックによって処理されされている）、または追加のブリッジよりも。しかし、それに私を釘付けしないでください。両方（macvlan / macvtap）が使用可能な同じモード（VEPA /ヘアピン、ブリッジング、プライベート）を共有することに加えて、スイッチが反射リレーモードをサポートしている場合にのみヘアピニングが機能します。（ポートxの物理スイッチに到着したパケットは、同じポートxで再びスイッチを離れることができなければなりません。）

eth0（または使用する方）はブリッジを使用するときに無差別モードになるため、macvXXXモードはスループットが高いと言われています。

モードは分離の「量」も定義します（vhostはお互いのトラフィックを見ることができますか？hvはどうですか？）。これが内部でどのように機能するかはまだわかりません。

veth（仮想イーサネットペア）は分離に関して多少似ています。2つの仮想インターフェイスを定義します。1つはブリッジに接続され、もう1つはVMに接続されます。そこで、vm-interfaceを独自の名前空間に配置することで分離が行われるため、デバイスはある程度分離されます。すべてのトラフィックはブリッジでまとめられますが、ある仮想ホストは別の仮想ホストを見ることができません。

ブリッジを使用する場合、追加の設定が必要です。ブリッジがダウンすると、すべての接続もダウンします。ブリッジを再起動するとき、すべての仮想インターフェイスをブリッジに再接続する必要があります（または、完全なhv ...を再起動するだけです）。

結論：トポロジを頻繁に変更しない場合は、オンラインで最も多くの情報を見つけるので、ブリッジを使用してください。これは、カーネルコードを読むよりも優れています。ちなみに、iproute2-docパッケージ自体でさえ、最先端のバージョンを実行していても、iproute2が実際に持っている情報のほとんどが欠けています。man ip-tcp_metrics利用可能なマンページまたはip-crefs.psから調べてみてください...

これらのメソッドは、根本的に異なることを行っています。その理由を理解するには、ネットワークの階層化モデルを理解する必要があります。ここでは、レイヤー1、2、3が重要です。

• レイヤー1は物理層です-これは、使用できるケーブル、そのケーブルの1と0を表す電圧/電流パターン、ケーブルの両端のデバイスが動作するビットレートをネゴシエートする方法などを指定します。
• レイヤー2はリンクレイヤーです-これは、ケーブルの各端でどの言語のものが互いに通信するかを指定します。この層のイーサネットデバイスには、フレームやMACアドレスなどがあります。
• レイヤー3はネットワークレイヤーです-これは、デバイスが別のデバイスへの直接のレイヤー2リンクを使用して、レイヤー2で直接到達できない3番目のデバイスに到達する方法を指定します。このレイヤーのデバイスにはIPアドレスとルーティングテーブルがあります。

MACVLAN / MACVTAP

MACVLANは、独自のMACアドレスを持つ仮想レイヤー2またはリンクレイヤーデバイスを作成し、レイヤー1または物理レイヤーを既存のデバイスと共有します。最も明らかに理解できるケースは、イーサネットデバイスをネットワークに接続し、そのイーサネットデバイスに基づいてMACVLANデバイスを作成する場合です。これで、異なるMACアドレスを持つ2つのイーサネット「デバイス」がありますが、どちらも同じケーブルでフレームを送信します。MACVTAPについてもう少し詳しく説明します。

MACVLANインターフェースは、特に他のインターフェースのアドレスであるインターフェースの1つにフレームが表示される場合、既存のイーサネットインターフェースといくつかの異なる方法で対話できます。

• でプライベートモードでは、フレームが捨てられています。2つのインターフェイスが外部デバイスとのみ通信することはできません。
• VEPAモードでは、フレームは他のフレームのような物理層を介して送信されます。デバイスがスイッチに接続されていて、フレームが到着した同じポートに送り返される必要があることを発見するのに十分賢い場合、それを送信したのと同じ物理層が受信し、レイヤー2はMACを使用して、目的のネットワークインターフェイスに送信します。
• でブリッジフレームは、一つのデバイスに表示されたときのモード、他のためのものであり、もしそうなら、それはレイヤ1を経由せずにそこに送信されたかどうかチェックされます。
• さらにいくつかの不明瞭なモードがあります。

MACVLANインターフェイスには重要な制限があることに注意してください。アドレス学習はできません。そのため、MACVLANインターフェイスを2番目の物理デバイスにブリッジして、最初の物理デバイスを介してその2番目の物理デバイスに到達できるとは期待できません。これは元のイーサネットインターフェイスで機能しますが、MACVLANインターフェイスが接続されている場合は機能しません。

TUN / TAP

TAPインターフェースも新しい仮想レイヤー2デバイスですが、レイヤー1は接続されていません。代わりに、プログラムは物理層を表すファイル記述子を取得できます。その後、生のイーサネットフレームデータをそのファイル記述子に書き込むことができ、カーネルはそれを実際の物理インターフェースで受信する他のイーサネットパケットと同様に扱います。

TAPインターフェースの大きな特徴は、物理層がユーザーモードになっていることです。適切な許可を持つソフトウェアのビットは、好きな方法でイーサネットフレームを生成し、カーネルが実際の物理インターフェースと同じように扱うものに押し込むことができます。これにより、VPNやトンネリングなどに非常に役立ちます。ユーザー空間に好きな種類のトンネリングソフトウェアを書くことができ、フレームをネットワークスタックに入れるためにカーネル空間に干渉する必要はありません。TAPデバイスを作成し、そのファイル記述子にフレームを書き込むだけです。

TUNデバイスはTAPデバイスに似ていますが、レイヤー2ではなくレイヤー3で動作し、ユーザーモードソフトウェアは生のイーサネットフレームではなく生のIPパケットをファイル記述子に書き込む必要があります。

MACVTAPデバイスに戻ると、これらはMACVLANとTAPインターフェース間の混同のようなものです。TAPインターフェイスと同様に、ユーザーモードプログラムはファイル記述子を取得して、そこに生のイーサネットフレームを書き込むことができます。MACVLANインターフェイスと同様に、これらのフレームは実際のイーサネットデバイスの物理層を介して送信されます。これにより、TAPデバイスを使用するように作成されたソフトウェアを簡単に調整して、代わりにMACVLANデバイスを使用できます。

VNet

これは概念的にはTUN / TAPネットワーキングに似ていますが、より高度なコントロールプレーン（それを使用するユーザーモードソフトウェアがインターフェイスをより柔軟に構成できるようになっています）およびより最適化されたデータプレーン（仮想ネットワークデバイスを介してデータを移動できるようになっています）効率的に）。

これらはすべて同様のことを行いますが、機能がわずかに異なります。それらはすべて、VMをイーサネットネットワークに接続するために使用できます。

• 仮想化製品は、ゲストからイーサネットフレームを取得して、TAPデバイスのファイル記述子に書き込むことができます。そのTAPデバイスには、ホストが独自のIPアドレスを割り当てるか、イーサネットインターフェイスとともにブリッジにスレーブ接続してホストのIPアドレスを共有したり、NATを使用してトラフィックを転送するようにiptablesを構成したりできます。
• 仮想化製品は、ゲストからのイーサネットフレームをMACVTAPデバイスのファイル記述子に書き込むことができます。これらはイーサネットデバイスの物理層で直接送信され、VMに「実際の」イーサネットデバイスを効果的に提供します（ただし、ブリッジなどの他のタイプのネットワークインターフェース用にMACVLAN / MACVTAPデバイスを作成できることに注意してください）。
• 仮想化製品は、ゲストのvirtioドライバーをホストのvirtioドライバーに接続して、非常に効率的なネットワーキングを実現できます。