tun / tap vs bridge + vnet vs macvtap有什么区别？（对于虚拟化KVM）

我刚刚发现了许多不同的方法来进行KVM网络连接。但是我一直坚持正确的方法。我发现openstack使用macvtap进行中子联网。而且看起来不错。

但是有什么区别以及为什么要使用每种方式。

方式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软件界面，但效果更好。不知道用什么方式，但这似乎更好。

与第二种方式相比，macvtap有什么优势？

有什么更好的？

有什么帮助吗？

这实际上取决于您要实现的目标

• TAP /屯

不管是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。应也有performanter比macvlan（其大致是添加另一MAC到物理设备，到达的相关信息有通过网络栈处理）或额外的桥，如macvtap直接以某种方式绕过网络堆栈和出口抽头字符设备。但是不要钉我。除了两种（macvlan / macvtap）共享相同的可用模式（VEPA /发夹，桥接，专用）之外，发夹仅在您的交换机支持反射中继模式时才起作用。（必须允许到达端口x的物理交换机的数据包再次将交换机留在同一端口x。）

因为使用网桥时eth0（或您使用的任何一个）被置于混杂模式，所以macvXXX模式被认为具有更高的吞吐量。

这些模式还定义了隔离的“数量”（虚拟主机能否看到彼此的流量？hv怎么样？）。我还不知道这是如何工作的。

veth（虚拟以太网对）在隔离方面有些相似，您定义了两个虚拟接口，一个连接到网桥，另一个连接到您的VM。隔离是通过将vm-interface放入其自己的名称空间来完成的，从而使设备有所隔离。所有流量都在网桥处汇聚在一起，但是一个虚拟主机看不到另一个虚拟网卡。

如果您使用网桥，则需要执行其他配置，并且当网桥关闭时，所有连接也将关闭。当重新建立网桥时，您可能必须重新将所有虚拟接口重新连接到网桥（或仅重新启动完整的硬件...）。

底线：如果您不经常更改拓扑，则只需进行桥接即可，因为您可以在线找到最多的信息，这比读取内核代码更好。哎呀，即使是iproute2-doc软件包本身也缺少iproute2实际拥有的大多数信息，即使您运行最新版本。尝试man ip-tcp_metrics从可用的联机帮助页或ip-crefs.ps中查找有关...

这些方法所做的根本不同。要了解原因，您需要了解网络的分层模型。对于我们这里的目的，第1、2和3层很重要：

• 第1层是物理层-规定了诸如可以使用的电缆，哪种电压/电流模式分别代表该电缆上的1和0，电缆两端的设备如何协商其工作的比特率等内容。
• 第2层是链接层-该层指定电缆两端互相交谈的语言。该层的以太网设备具有诸如帧和MAC地址之类的东西。
• 第3层是网络层-这指定了设备如何使用直接到其他设备的第2层链接来到达第2层不能直接到达的第三个设备。该层的设备具有IP地址和路由表。

MACVLAN / MACVTAP

MACVLAN使用自己的MAC地址创建一个虚拟的第2层或链路层设备，该MAC地址与现有设备共享第1层或物理层。最明显的情况是将以太网设备插入网络，并基于该以太网设备创建MACVLAN设备。现在，您有两个具有不同MAC地址的以太网“设备”，但它们都在同一根电缆上传输其帧。我将进一步讨论MACVTAP。

MACVLAN接口可以与现有的以太网接口以几种不同的方式进行交互，尤其是当其中一个帧出现在另一个接口的地址上时：

• 在私有模式下，帧被丢弃；这两个接口不可能仅与外部设备相互通信。
• 在vepa模式下，该帧像其他任何帧一样在物理层上发送。如果您将设备插入足够聪明的交换机以发现该帧，则需要将该帧发送回它到达的同一端口，那么该帧将由发送该帧的同一物理层接收，然后第二层将使用MAC将其发送到预期的网络接口。
• 在桥接模式下，当一帧出现在一个设备上时，将检查该帧是否用于另一设备，如果是，则将其发送到那里而无需经过第1层。
• 还有一些更晦涩的模式。

请注意，MACVLAN接口有一个重要的限制：它们无法进行地址学习。因此，您无法将MACVLAN接口桥接到第二台物理设备，并期望能够通过第一台物理设备访问该第二台物理设备。这适用于原始的以太网接口，但不适用于附加的MACVLAN接口。

TUN / TAP

TAP接口也是新的虚拟第2层设备，但没有连接第1层。相反，程序可以获取代表物理层的文件描述符。然后，它可以将原始以太网帧数据写入该文件描述符，并且内核将像对待它在实际物理接口上接收到的任何其他以太网数据包一样对待它。

TAP接口的重要之处在于，物理层处于用户模式。任何具有适当权限的软件都可以按照自己喜欢的任何方式生成以太网帧，并将其推送到内核将其视为真实物理接口的位置。这使它们对于VPN和隧道化非常有用。您可以在用户空间中编写任意类型的隧道软件，而无需干预内核空间即可将帧放入网络堆栈中，只需创建TAP设备并将帧写入其文件描述符即可。

TUN设备类似于TAP设备，不同之处在于它们运行在第3层而不是第2层，并且用户模式软件必须将原始IP数据包写入文件描述符，而不是原始以太网帧。

回到MACVTAP设备，这些是MACVLAN和TAP接口之间的某种混合。像TAP接口一样，用户模式程序可以获取文件描述符并将原始以太网帧写入其中。像MACVLAN接口一样，这些帧随后通过真实以太网设备的物理层发送。这使您可以轻松地将为使用TAP设备编写的软件改编为使用MACVLAN设备。

虚拟网络

这在概念上类似于TUN / TAP网络，但是具有更发达的控制平面（因此使用它的用户模式软件可以更灵活地配置接口）和更优化的数据平面（因此您可以在虚拟网络设备中移动更多数据）有效率的）。

所有这些都做类似的事情，但是功能略有不同。所有这些都可用于将VM连接到以太网：

• 虚拟化产品可以从来宾中获取以太网帧，并将其写入TAP设备的文件描述符中。主机可以为该TAP设备分配其自己的IP地址，也可以将其与以太网接口一起从属于桥接器，以共享主机的IP地址，也可以将iptables配置为使用NAT转发其上的流量。
• 虚拟化产品可以使来宾中的以太网帧并写入到MACVTAP设备的文件描述符中。然后，这些数据将直接在以太网设备的物理层上进行传输，从而有效地为VM提供了一个“真正的”以太网设备（尽管请注意，可以为其他类型的网络接口（例如网桥）创建MACVLAN / MACVTAP设备）。
• 虚拟化产品可以将客户机中的virtio驱动程序连接到主机中的virtio驱动程序，以实现非常有效的联网。