Linux上的物理网卡与虚拟网络设备

通过 ip link add 可以创建多种类型的虚拟网络设备，在 man ip link 中可以得知有以下类型的device:

Virtual Ethernet Port Aggregator。它是HP在虚拟化支持领域对抗Cisco的VN-Tag的技术。

解决了虚拟机之间网络通信的问题，特别是位于同一个宿主机内的虚拟机之间的网络通信问题。

VN-Tag在标准的协议头中增加了一个全新的字段，VEPA则是通过修改网卡驱动和交换机，通过发夹弯技术回注报文。

TUN是Linux系统里的虚拟网络设备，它的原理和使用在 Kernel Doc 和 Wiki 做了比较清楚的说明。

TUN设备模拟网络层设备(network layer)，处理三层报文，IP报文等，用于将报文注入到网络协议栈。

应用程序(app)可以从物理网卡上读写报文，经过处理后通过TUN回送，或者从TUN读取报文处理后经物理网卡送出。

创建:

创建之后，使用 ip addr 就会看见一个名为”tun-default”的虚拟网卡

可以对tun-default设置IP:

使用open/write等文件 *** 作函数从fd中进行读取 *** 作，就是在收取报文，向fd中写入数据，就是在发送报文。

TAP是Linux系统里的虚拟网络设备，它的原理和使用在 Kernel Doc 和 Wiki 做了比较清楚的说明。

不同于TUN的是，TAP设备模拟链路层设备(link layer)，处理二层报文，以太网帧等。

TAP设备的创建过程和TUN类似，在ioctl设置的时候，将类型设置为IFF_TAP即可。

TAP设备与TUN设备的区别在于:

有时我们可能需要一块物理网卡绑定多个 IP 以及多个 MAC 地址，虽然绑定多个 IP 很容易，但是这些 IP 会共享物理网卡的 MAC 地址，可能无法满足我们的设计需求，所以有了 MACVLAN 设备，其工作方式如下：

MACVLAN 会根据收到包的目的 MAC 地址判断这个包需要交给哪个虚拟网卡。单独使用 MACVLAN 好像毫无意义，但是配合之前介绍的 network namespace 使用，我们可以构建这样的网络：

采摘

创建一个基于eth0的名为macv1的macvlan网卡:

macvlan支持三种模式，bridge、vepa、private，在创建的时候设置“mode XXX”:

bridge模式，macvlan网卡和物理网卡直接可以互通，类似于接入到同一个bridge。

vepa模式下，两个macvlan网卡直接不能直接通信，必须通过外部的支持“发夹弯”交换机才能通信。

private模式下，macvlan发出的广播包（arp等）被丢弃，即使接入了支持“发夹弯”的交换机也不能发现其它macvlan网卡，除非手动设置mac。

MACVTAP 是对 MACVLAN的改进，把 MACVLAN 与 TAP 设备的特点综合一下，使用 MACVLAN 的方式收发数据包，但是收到的包不交给 network stack 处理，而是生成一个 /dev/tapX 文件，交给这个文件：

由于 MACVLAN 是工作在 MAC 层的，所以 MACVTAP 也只能工作在 MAC 层，不会有 MACVTUN 这样的设备。

ipvlan和macvlan的区别在于它在ip层进行流量分离而不是基于mac地址，同属于一块宿主以太网卡的所有ipvlan虚拟网卡的mac地址都是一样的。

[图片上传失败...(image-d98b6f-1597455459947)]

veth设备是成对创建的：

创建之后，执行 ip link 就可以看到新创建的veth设备：

注意veth设备前面的ID， 58: 和 59: ，一对veth设备的ID是相差1的，并且系统内全局唯一。可以通过ID找到一个veth设备的对端。

veth设备理解

Intermediate Functional Block device，连接 ifb 中做了很详细的介绍。

参考： TC - Linux 流量控制工具 | Life is magic. Coding is art. (int64.me)

TC(Linux下流量控制工具)详细说明及应用_Gino的专栏-CSDN博客

本来打算直接列一波用法，但是总觉得，不记录一下原理， *** 作起来也是一脸懵逼。 TC 通过建立处理数据包队列，并定义队列中数据包被发送的方式，从而实现进行流量控制。TC 模拟实现流量控制功能使用的队列分为两类：

classful 队列规定（qdisc）, 类（class）和过滤器（filter）这 3 个组件组成，绘图中一般用圆形表示队列规定，用矩形表示类，图 copy 自 Linux 下 TC 以及 netem 队列的使用

都是以一个根 qdisc 开始的，若根 qdisc 是不分类的队列规定，那它就没有子类，因此不可能包含其他的子对象，也不会有过滤器与之关联，发送数据时，数据包进入这个队列里面排队，然后根据该队列规定的处理方式将数据包发送出去。

分类的 qdisc 内部包含一个或多个类，而每个类可以包含一个队列规定或者包含若干个子类，这些子类友可以包含分类或者不分类的队列规定，如此递归，形成了一个树。

句柄号：qdisc 和类都使用一个句柄进行标识，且在一棵树中必须是唯一的，每个句柄由主号码和次号码组成 qdisc 的次号码必须为 0（0 通常可以省略不写）

根 qdisc 的句柄为 1：，也就是 1：0。类的句柄的主号码与它的父辈相同（父类或者父 qdisc），如类 1：1 的主号码与包含他的队列规定 1：的主号码相同，1：10 和 1：11 与他们的父类 1：1 的主号码相同，也为 1。

新建一个类时，默认带有一个 pfifo_fast 类型的不分类队列规定，当添加一个子类时，这个类型的 qdisc 就会被删除，所以，非叶子类是没有队列规定的，数据包最后只能到叶子类的队列规定里面排队。

若一个类有子类，那么允许这些子类竞争父类的带宽，但是，以队列规定为父辈的类之间是不允许相互竞争带宽的。

默认 TC 的 qdisc 控制就是出口流量，要使用 TC 控制入口，需要把流量重定向到 ifb 网卡，其实就是加了一层，原理上还是控制出口 。

为何要先说 classless 队列，毕竟这个简单嘛，要快速使用，那么这个就是首选了。基于 classless 队列，我们可以进行故障模拟，也可以用来限制带宽。

TC 使用 linux network netem 模块进行网络故障模拟

网络传输并不能保证顺序，传输层 TCP 会对报文进行重组保证顺序，所以报文乱序对应用的影响比上面的几种问题要小。

报文乱序可前面的参数不太一样，因为上面的报文问题都是独立的，针对单个报文做 *** 作就行，而乱序则牵涉到多个报文的重组。模拟报乱序一定会用到延迟（因为模拟乱序的本质就是把一些包延迟发送），netem 有两种方法可以做。

以 tbf (Token Bucket Filter) 为例，

参数说明：

限制 100mbit

限制延迟 100ms, 流量 100mbit

这个就复杂一些，同样也特别灵活，可以限制特定的 ip 或者服务类型以及端口

以使用 htb 为例

使用 TC 进行入口限流，需要把流量重定向到 ifb 虚拟网卡，然后在控制 ifb 的输出流量

---