linux 创建虚拟网卡的几种 --- （Linux源码树：基于Netnamespace

惠普笔记本网卡驱动背后的Linux源码树：基于NetNamespace虚拟网卡技术的

随着虚拟化技术的飞速发展，Linux内核源码树中对虚拟化的支持也日趋完善。其中，NetNamespace技术作为轻量级的虚拟化解决方案，广泛应用于Linux系统中，特别是在网络领域。惠普笔记本的网卡驱动在Linux源码树中也基于这一技术进行了深入开发。

Linux内核中的网卡驱动包含了许多虚拟网卡。早期的技术如tun和ifb已经被详细过。随着虚拟化技术的盛行，Linux源码树中对虚拟化的支持愈加丰富，为用户和程序员提供了更多选择。这些技术涵盖了各种虚拟化需求，从重量级的虚拟机技术到轻量级的NetNamespace技术。

NetNamespace技术提供了一种简单有效的方案，让每个namespace拥有独立的协议栈和网卡。这种技术对于模拟多客户端连接特别有用，操作简单。对于嵌入式系统的开发者来说，这一技术更是不可或缺。我已经写过关于NetNamespace的文章，通过详细的步骤指导，读者可以轻松地完成相关配置和应用开发。

在Linux系统中，虚拟网卡的使用场景并不仅限于NetNamespace。重量级的虚拟机也可以利用这些技术。之所以选择NetNamespace为例进行介绍，是因为其简单性。实际上，虚拟网卡的原理是通用的，具体使用场景则取决于我们的想象力。

虚拟化技术在中指的是主机中的虚拟化，特别是在一台物理主机中分离出多个TCP/IP协议栈的技术。这种虚拟化可以独立实现，也可以依托其他技术如虚拟机技术来实现。每个虚拟机内部都有自己的协议栈，这种依托虚拟机技术实现的虚拟化可能更加简单。宿主机不需要实现一个完整的协议栈，而是将这个任务交给虚拟机的操作系统来完成。

理解虚拟网卡的要旨在于理解网卡的作用和位置。网卡作为一道门或接口，连接着协议栈和物理介质。关键在于明确网卡所连接的具体内容。由于网卡的上接口在操作系统中实现，或者使用PF技术在用户态实现，因此它们是软件定义的，可以任意实现。下接口连接的是物理介质，如双绞线和光纤等，这部分则受到物理世界的限制。

数据在宿主网卡和虚拟网卡之间的路由方式多种多样。早期的内核中，对bridge的支持是通过硬编码的钩子来实现的。随着虚拟网卡的种类增多，这种硬编码的方式显得不够灵活。内核开发者提出了一种新的方式，将钩子抽象为更高层次的结构，不再硬编码，而是在netif_receive_skb中调用唯一的rx_handler钩子。这种变化使得内核更加灵活和可扩展。

深入虚拟网卡设置：宿主网卡与多种虚拟技术的交融

对于不同的虚拟网卡类型，如bridge、bonding、MACVLAN、IPVLAN等，其钩子设置与宿主网卡的绑定息息相关。每一块宿主网卡，如同网络世界的交通枢纽，只能注册一个rx_handler，却能承载众多不同类型的虚拟网卡，它们之间的关系犹如乐章中的和谐旋律，叠加而又不冲突。

让我们聚焦在VETH虚拟网卡技术上。正如我在《Open×××多处理之-netns容器与iptables CLUSTER》中所提及，每一个VETH网卡都是一对以太网卡。它们之间的数据传输如同点对点通信，通过xmit接口将数据发送到其peer，触发其peer的RX。那么，这些数据是如何跨越VETH网卡对外的呢？答案是明确的：

1. 若需将数据发送到外部，可以通过将一块VETH网卡与一块普通ETHx网卡进行bridge连接。通过bridge的逻辑，数据可以被forward到ETHx，进而传输出去。

2. 难道非得将数据发送到外部吗？不，使用VETH可以在同一台机器的不同net namespace之间隐秘地传输数据，类似于loopback设备那样自发自收，同时保证数据的私密性，不被外部嗅探到。

VETH虚拟网卡的原理简单直观。它通过连接不同的net namespace，以UNIX的风格展现网络的原始朴素面貌。要想完成net namespace的隔离以及数据的发送，可能需要借助其他技术或工具来实现。

再来看MACVLAN虚拟网卡技术。MACVLAN可以说是将一块以太网卡虚拟成多块的最简单方案。以往我们只能为一块以太网卡添加多个IP地址，而MACVLAN技术打破了这一限制，让你能够为一块以太网卡添加多个MAC地址。这就像是将双绞线物理上每根一分为二，虽然还是共享介质，但是现代的全双工模式以太网卡可以处理这种变化。

MACVLAN技术的流程可以这样理解：通过命令创建一个基于eth0的MACVLAN虚拟网卡。这个虚拟网卡在实际操作中就像是一个独立存在的实体，尽管它是基于宿主网卡eth0构建的。这就像是在已经建立的复杂以太网环境中引入了新的交互元素，这些元素之间的关系决定了MACVLAN的行为模式。其中bridge模式只是针对同属于一块宿主以太网卡的MACVLAN网卡与宿主网卡之间的通信行为，与外部通信无关。

网络技术的：Bridge、VEPA与MACVLAN

在网络技术的高级特性时，我们经常会遇到几个概念：Bridge、VEPA模式和MACVLAN。这些技术各有其独特之处，深入理解它们对于构建高效、稳定的网络环境至关重要。

一、Bridge模式

Bridge模式在网络中扮演着数据流转发的关键角色。在这种模式下，网卡之间的数据流可以直接转发，无需外部协助。这就像在Linux BOX中通过brctl命令建立一个桥梁，实现不同网卡之间的无缝连接。

二、VEPA模式

VEPA模式（Virtual Ethernet Port Aggregator）是HP在虚拟化领域对抗Cisco的VN-Tag的技术。它主要解决虚拟机之间的通信问题，特别是在同一宿主机内的虚拟机。尽管许多虚拟机技术内置了交叉功能，可以满足虚拟机之间的通信需求，但在扩展性和职责边界问题上，VEPA和VN-Tag技术应运而生。这些内置于虚拟机软件的虚拟交换机虽然能让用户体验到虚拟机间的通信，但在性能和功能上可能无法达到完美。更复杂的配置任务和故障处理变得棘手：系统管理员可能不熟悉协议细节，而专业网管无法触及这些内置于宿主服务器内部的设备。这就为VEPA和类似技术提供了存在的价值。

三、MACVLAN模式

相较于VEPA模式，MACVLAN模式的隔离强度更高。即使在配备在同一物理网卡上的MACVLAN子网之间，通信也需要通过外部交换机进行，通常是支持“发夹弯”转发的交换机。而在private模式下，广播和多播流量被严格隔离，这是因为以太网本身是广播依赖的，隔离广播就意味着失去了部分以太网的功能。配置MACVLAN模式时，可以使用ip link命令并添加mode参数来指定所需的模式（bridge、vepa或private）。

四、VETH网卡与MACVLAN网卡的异同

为了配置独立的net namespace，我们可以选择使用VETH或MACVLAN方式。VETH是一种虚拟以太网设备，可以通过ip netns添加net namespace并创建相应的虚拟接口来实现网络通信。而MACVLAN则是一种基于物理网卡的虚拟网络接口，可以看作是物理网卡的一个或多个虚拟副本。相较于VETH，MACVLAN的配置更为简洁。在bridge、VEPA和private模式下，MACVLAN和VETH的效率有所不同，但核心原理都是实现虚拟网络接口与物理网络的连接。

总结而言，Bridge、VEPA和MACVLAN都是网络虚拟化领域的重要技术。它们各自解决了不同的问题，提供了灵活的解决方案来满足不同的网络需求。深入理解这些技术的原理和特性，对于网络管理员和系统管理员来说是非常重要的。在面临尴尬场景时，它总是率先提出一个标准，引领行业前行。这一次，它改造了以太网协议，推出了VN-Tag，如同ISL之于IEEE802.1q一样，展现了其在网络技术领域的领导力。VN-Tag通过在标准协议头中增加全新字段，实现了网络数据的精准传输。这一切的背后，是Cisco凭借其超凡的技术实力，以最快的速度推出一款设备并让其真正运行起来的成果。

每一家厂商都有着自己的技术路径与选择。HP的反击策略独具特色。虽无法像Cisco那样修改协议头，但它通过调整协议行为来解决问题。虽然步伐稍晚，但HP提出的VEPA解决方案展现了一种更加开放的方式。Linux操作系统能够轻易地增加对其的支持，显示出VEPA的普及潜力和跨平台优势。

深入理解VEPA，我们会发现它看似毫无意义的做法实则蕴含着巨大的智慧。在一个数据包从交换机的一个网口进入再发出的过程中，VEPA没有改变以太网的协议头。这种处理方式在常规环境下看似多余，因为在单一物理宿主机上，自我发送的数据不会到达网卡，通常会被Loopback机制绕过。但在虚拟化场景中，情况截然不同。物理宿主机上的以太网卡发出的数据包可能来自不同的虚拟机或Linux的net namespace。在虚拟化环境下，一块物理网卡被虚拟成多块虚拟网卡，每一块虚拟网卡服务于一个虚拟机。如果没有修改以太网协议头且没有内置的虚拟交换机，就需要外部交换机协助转发。HP的VEPA方案在这种情况下应运而生，它不需要对硬件做任何修改，只需在软件和驱动层面进行调整。交换机的改动也十分有限，主要是在MAC/Port映射表查询失败时，将数据包广播到所有端口。STP协议的修改也类似。

对于不支持VEPA的厂商如Intel和Cisco来说，他们拥有大量生产网卡和设备的实力，从而在一定程度上控制硬件标准。但对于支持VEPA的交换机来说，其实现方式相对简单，仅需支持一种“发夹弯”模式即可。而IPVLAN虚拟网卡技术则提供了一种在IP层进行流量分离的方案，它与MACVLAN的区别在于其基于IP地址而非MAC地址进行流量划分。属于同一宿主以太网卡的所有IPVLAN虚拟网卡的MAC地址相同，因为宿主网卡并不依赖MAC地址进行流量分流。创建IPVLAN的命令简单明了，具体操作方式与MACVLAN类似。在选择使用哪种技术时，需要根据具体需求和场景进行评估。深入Linux虚拟网卡技术：IPVLAN与MACVTAP的

在Linux系统中，虚拟网卡技术扮演着至关重要的角色。其中，IPVLAN与MACVTAP是两种广泛应用的虚拟网卡技术。将深入这两种技术，帮助读者深入理解其原理及应用场景。

一、IPVLAN技术

IPVLAN作为一种虚拟网络接口，其工作原理与物理网卡类似。在Linux源码树中，IPVLAN技术基于Document，为开发者提供了丰富的资源和指导。该技术主要有两种模式：L2模式和L3模式。

在L2模式下，TX处理发生在连接到从设备的堆栈实例上，数据包被切换到主设备并排队以发送。在此模式下，从设备将接收并发送多播和广播流量。而在L3模式下，TX处理在L3层次发生在从设备的堆栈实例上，数据包被切换到主设备的堆栈实例进行L2处理和路由，然后从该实例将数据包排队在出站设备上。此模式下，从设备不能接收或发送多播/广播流量。

那么，何时选择IPVLAN技术呢？当面临以下情况时，可以考虑使用IPVLAN：外部交换机/路由器连接的Linux主机只允许每个端口一个MAC；在主机上创建的虚拟设备数量超过MAC容量，需要关注网络性能降级；或者当需要将从设备置于敌对/不受信任的网络命名空间时，其中L2在从设备上可能会被更改/滥用。

二、MACVTAP虚拟网卡技术

MACVTAP是一种用户态可访问的虚拟网卡技术。在用户态实现的虚拟机或模拟器运行OS时，如何模拟网卡呢？当实现一个与内核协议栈完全独立的用户态协议栈时，如何路由物理网卡的流量到用户态或反向路由用户态数据到BOX外部呢？这时，MACVTAP技术就派上了用场。

MACVTAP的实现很简单，只需要修改rx_handler。宿主以太网卡收到包后，不交给MACVLAN的虚拟网卡接口连接的协议栈，而是发送到字符设备队列。这就是MACVTAP的基本原理。

IPVLAN和MACVTAP都是强大的虚拟网卡技术，它们在不同的应用场景中有各自的优势。深入理解这些技术，将有助于更好地应用它们解决实际问题。对于Linux开发者与爱好者来说，掌握这些技术无疑是提升内核技术交流能力的重要一环。

仅提供了一个简要的介绍和，想要深入了解这些技术，还需要阅读相关文档、源码以及参与实际项目实践。希望能为你提供一个良好的起点。