tun/tap vs bridge+vnet vs macvtap 有什么区别?(用于虚拟化 KVM)

Gon*_*ado 30 networking virtualization

我刚刚发现了很多不同的方式来进行 KVM 网络。但我对什么是正确的做法感到困惑。我发现 openstack 使用 macvtap 来做中子网络。它看起来不错。

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

方式 1 [旧?调谐/敲击]

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

/--------\   /----\   /----\   /----\   /--------\
|Internet|---|eth0|---|br0 |---|tap0|---|Guest NIC
\--------/   \----/   \----/   \----/   \--------/
Run Code Online (Sandbox Code Playgroud)

已弃用,对吗?

方式 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
Run Code Online (Sandbox Code Playgroud)

当您从 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 与第二种方式相比有什么优势?

什么更好?

这有什么帮助吗?

Tom*_*Tom 8

这些方法正在做根本不同的事情。要了解原因,您需要了解网络的分层模型。就我们的目的而言,第 1、2 和 3 层很重要:

  • 第 1 层是物理层 - 它指定了诸如可以使用哪些电缆、代表该电缆上的 1 和 0 的电压/电流模式、电缆两端的设备如何协商其运行的比特率等内容。
  • 第 2 层是链路层 - 它指定电缆两端相互通信的语言。这一层的以太网设备具有帧和 MAC 地址等内容。
  • 第 3 层是网络层 - 它指定设备如何使用到另一个设备的直接第 2 层链路来到达它们在第 2 层无法直接到达的第三个设备。该层的设备具有 IP 地址和路由表。

MACVLAN / MACVTAP

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

MACVLAN 接口可以通过多种不同的方式与现有以太网接口进行交互,特别是当其中一个接口上出现一个帧(该帧是指向另一个接口的地址)时:

  • 私有模式下,框架被丢弃;两个接口不可能相互通信,只能与外部设备通信。
  • vepa模式下,帧像任何其他帧一样通过物理层发送。如果您将设备插入一个交换机,该交换机足够聪明,可以发现帧需要从它到达的同一端口发送回,那么它将被发送它的同一物理层接收,然后第 2 层将使用 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网络,但具有更发达的控制平面(因此使用它的用户模式软件可以更灵活地配置接口)和更优化的数据平面(因此您可以更通过虚拟网络设备移动数据)有效率的)。

所有这些都做类似的事情,但功能略有不同。所有这些都可用于将虚拟机连接到以太网:

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


j3f*_*ang 4

这实际上取决于您到底想要实现什么

  • 攻/调

不管是虚拟机还是物理机。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 桥”将 VNET(从虚拟机)桥接到物理以太网。如果您想要虚拟机(基于 KVM),则主机上的 vnet 和以太网之间必须有桥接


sja*_*jas 2

我想说这取决于你的用例。

自动添加/删除虚拟主机?

尝试一下 macvtap。还应该比 macvlan (这大致就像向物理设备添加另一个 MAC,到达那里的信息由网络堆栈处理)或附加桥性能更高,因为 macvtap 以某种方式绕过网络堆栈并直接导出分接字符设备。但别让我在这一点上固执己见。除了两者(macvlan/macvtap)共享相同的可用模式(VEPA/发夹、桥接、专用)之外,发夹仅在您的交换机支持反射中继模式时才起作用。(到达物理交换机端口 x 的数据包必须允许在同一端口 x 上再次离开交换机。)

由于 eth0(或您使用的任何一个)在使用网桥时被置于混杂模式,因此 macvXXX 模式据说具有更高的吞吐量。

这些模式还定义了隔离的“量”(虚拟主机可以看到彼此的流量吗?hv 怎么样?)。我还不知道这在幕后是如何运作的。

veth(虚拟以太网对)在隔离方面有点类似,您定义两个虚拟接口,一个连接到网桥,另一个连接到虚拟机。在那里,隔离是通过将虚拟机接口放入它自己的命名空间中来完成的,因此设备在某种程度上是隔离的。所有流量都在桥上汇集,但一个虚拟主机无法看到另一个虚拟主机的虚拟网卡。

如果您使用网桥,则需要进行额外的配置,并且当网桥关闭时,您的所有连接也会关闭。当恢复网桥时,您可能必须重新将所有虚拟接口重新连接到网桥(或者只是重新启动整个 hv...)。

底线:如果您不经常更改拓扑,只需使用桥接,因为您可以在网上找到最多的信息,这比阅读内核代码更好。哎呀,即使是 iproute2-doc 包本身也缺乏 iproute2 实际拥有的大部分信息,即使您运行的是前沿版本。尝试从可用的联机帮助页或 ip-crefs.ps 中查找man ip-tcp_metrics...