linux虚拟网络设备之bridge(桥)（三）
继前两篇介绍了tun/tap和veth之后，本篇将介绍Linux下常用的一种虚拟网络设备，那就是bridge(桥)。
本篇将通过实际的例子来一步一步解释bridge是如何工作的。
什么是bridge？
首先，bridge是一个虚拟网络设备，所以具有网络设备的特征，可以配置IP、MAC地址等；其次，bridge是一个虚拟交换机，和物理交换机有类似的功能。
对于普通的网络设备来说，只有两端，从一端进来的数据会从另一端出去，如物理网卡从外面网络中收到的数据会转发给内核协议栈，而从协议栈过来的数据会转发到外面的物理网络中。
而bridge不同，bridge有多个端口，数据可以从任何端口进来，进来之后从哪个口出去和物理交换机的原理差不多，要看mac地址。
创建bridge
我们先用iproute2创建一个bridge：
dev@debian:~$ sudo ip link add name br0 type bridge
dev@debian:~$ sudo ip link set br0 up
当刚创建一个bridge时，它是一个独立的网络设备，只有一个端口连着协议栈，其它的端口啥都没连，这样的bridge没有任何实际功能，如下图所示：
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Network Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ |
|..............|................................|................|
| ↓ ↓ |
| +----------+ +------------+ |
| | eth0 | | br0 | |
| +----------+ +------------+ |
| 192.168.3.21 ↑ |
| | |
| | |
+--------------|-------------------------------------------------+↓Physical Network
这里假设eth0是我们的物理网卡，IP地址是192.168.3.21，网关是192.168.3.1
将bridge和veth设备相连
创建一对veth设备，并配置上IP
dev@debian:~$ sudo ip link add veth0 type veth peer name veth1
dev@debian:~$ sudo ip addr add 192.168.3.101/24 dev veth0
dev@debian:~$ sudo ip addr add 192.168.3.102/24 dev veth1
dev@debian:~$ sudo ip link set veth0 up
dev@debian:~$ sudo ip link set veth1 up
将veth0连上br0
dev@debian:~$ sudo ip link set dev veth0 master br0
//通过bridge link命令可以看到br0上连接了哪些设备
dev@debian:~$ sudo bridge link
6: veth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
这时候，网络就变成了这个样子:
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Network Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ | ↑ |
|............|............|..............|............|..........|
| ↓ ↓ ↓ ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | .3.21| | | | .3.101| | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 | | br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+↓Physical Network
这里为了画图方便，省略了IP地址前面的192.168，比如.3.21就表示192.168.3.21
br0和veth0相连之后，发生了几个变化：
- br0和veth0之间连接起来了，并且是双向的通道
- 协议栈和veth0之间变成了单通道，协议栈能发数据给veth0，但veth0从外面收到的数据不会转发给协议栈
- br0的mac地址变成了veth0的mac地址
相当于bridge在veth0和协议栈之间插了一脚，在veth0上面做了点小动作，将veth0本来要转发给协议栈的数据给拦截了，全部转发给bridge了，同时bridge也可以向veth0发数据。
下面来检验一下是不是这样的：
通过veth0 ping veth1失败：
dev@debian:~$ ping -c 1 -I veth0 192.168.3.102
PING 192.168.2.1 (192.168.2.1) from 192.168.2.11 veth0: 56(84) bytes of data.
From 192.168.2.11 icmp_seq=1 Destination Host Unreachable--- 192.168.2.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
为什么veth0加入了bridge之后，就ping不通veth2了呢？ 先抓包看看：
#由于veth0的arp缓存里面没有veth1的mac地址，所以ping之前先发arp请求
#从veth1上抓包来看，veth1收到了arp请求，并且返回了应答
dev@debian:~$ sudo tcpdump -n -i veth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes
21:43:48.353509 ARP, Request who-has 192.168.3.102 tell 192.168.3.101, length 28
21:43:48.353518 ARP, Reply 192.168.3.102 is-at 26:58:a2:57:37:e9, length 28#从veth0上抓包来看，数据包也发出去了，并且也收到了返回
dev@debian:~$ sudo tcpdump -n -i veth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:44:09.775392 ARP, Request who-has 192.168.3.102 tell 192.168.3.101, length 28
21:44:09.775400 ARP, Reply 192.168.3.102 is-at 26:58:a2:57:37:e9, length 28#再看br0上的数据包，发现只有应答
dev@debian:~$ sudo tcpdump -n -i br0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:45:48.225459 ARP, Reply 192.168.3.102 is-at 26:58:a2:57:37:e9, length 28
从上面的抓包可以看出，去和回来的流程都没有问题，问题就出在veth0收到应答包后没有给协议栈，而是给了br0，于是协议栈得不到veth1的mac地址，从而通信失败。
给bridge配上IP
通过上面的分析可以看出，给veth0配置IP没有意义，因为就算协议栈传数据包给veth0，应答包也回不来。这里我们就将veth0的IP让给bridge。
dev@debian:~$ sudo ip addr del 192.168.3.101/24 dev veth0
dev@debian:~$ sudo ip addr add 192.168.3.101/24 dev br0
于是网络变成了这样子：
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Network Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ ↑ |
|............|............|...........................|..........|
| ↓ ↓ ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | .3.21| | .3.101 | | | | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 | | br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+↓Physical Network
其实veth0和协议栈之间还是有联系的，但由于veth0没有配置IP，所以协议栈在路由的时候不会将数据包发给veth0，就算强制要求数据包通过veth0发送出去，但由于veth0从另一端收到的数据包只会给br0，所以协议栈还是没法收到相应的arp应答包，导致通信失败。
这里为了表达更直观，将协议栈和veth0之间的联系去掉了，veth0相当于一根网线。
再通过br0 ping一下veth1，结果成功
dev@debian:~$ ping -c 1 -I br0 192.168.3.102
PING 192.168.3.102 (192.168.3.102) from 192.168.3.101 br0: 56(84) bytes of data.
64 bytes from 192.168.3.102: icmp_seq=1 ttl=64 time=0.121 ms--- 192.168.3.102 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.121/0.121/0.121/0.000 ms
但ping网关还是失败，因为这个bridge上只有两个网络设备，分别是192.168.3.101和192.168.3.102，br0不知道192.168.3.1在哪。
dev@debian:~$ ping -c 1 -I br0 192.168.3.1
PING 192.168.3.1 (192.168.3.1) from 192.168.3.101 br0: 56(84) bytes of data.
From 192.168.3.101 icmp_seq=1 Destination Host Unreachable--- 192.168.3.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
将物理网卡添加到bridge
将eth0添加到br0上：
dev@debian:~$ sudo ip link set dev eth0 master br0
dev@debian:~$ sudo bridge link
2: eth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 4
6: veth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
br0根本不区分接入进来的是物理设备还是虚拟设备，对它来说都一样的，都是网络设备，所以当eth0加入br0之后，落得和上面veth0一样的下场，从外面网络收到的数据包将无条件的转发给br0，自己变成了一根网线。
这时通过eth0来ping网关失败，但由于br0通过eth0这根网线连上了外面的物理交换机，所以连在br0上的设备都能ping通网关，这里连上的设备就是veth1和br0自己，veth1是通过veth0这根网线连上去的，而br0可以理解为自己有一块自带的网卡。
#通过eth0来ping网关失败
dev@debian:~$ ping -c 1 -I eth0 192.168.3.1
PING 192.168.3.1 (192.168.3.1) from 192.168.3.21 eth0: 56(84) bytes of data.
From 192.168.3.21 icmp_seq=1 Destination Host Unreachable--- 192.168.3.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms#通过br0来ping网关成功
dev@debian:~$ ping -c 1 -I br0 192.168.3.1
PING 192.168.3.1 (192.168.3.1) from 192.168.3.101 br0: 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=27.5 ms--- 192.168.3.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.518/27.518/27.518/0.000 ms#通过veth1来ping网关成功
dev@debian:~$ ping -c 1 -I veth1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) from 192.168.3.102 veth1: 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=68.8 ms--- 192.168.3.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 68.806/68.806/68.806/0.000 ms
由于eth0已经变成了和网线差不多的功能，所以在eth0上配置IP已经没有什么意义了，并且还会影响协议栈的路由选择，比如如果上面ping的时候不指定网卡的话，协议栈有可能优先选择eth0，导致ping不通，所以这里需要将eth0上的IP去掉。
#在本人的测试机器上，由于eth0上有IP，
#访问192.168.3.0/24网段时，会优先选择eth0
dev@debian:~$ sudo route -v
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.3.1 0.0.0.0 UG 0 0 0 eth0
link-local * 255.255.0.0 U 1000 0 0 eth0
192.168.3.0 * 255.255.255.0 U 0 0 0 eth0
192.168.3.0 * 255.255.255.0 U 0 0 0 veth1
192.168.3.0 * 255.255.255.0 U 0 0 0 br0#由于eth0已结接入了br0，所有它收到的数据包都会转发给br0，
#于是协议栈收不到arp应答包，导致ping失败
dev@debian:~$ ping -c 1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
From 192.168.3.21 icmp_seq=1 Destination Host Unreachable--- 192.168.3.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms#将eth0上的IP删除掉
dev@debian:~$ sudo ip addr del 192.168.3.21/24 dev eth0#再ping一次，成功
dev@debian:~$ ping -c 1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=3.91 ms--- 192.168.3.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.916/3.916/3.916/0.000 ms#这是因为eth0没有IP之后，路由表里面就没有它了，于是数据包会从veth1出去
dev@debian:~$ sudo route -v
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.3.0 * 255.255.255.0 U 0 0 0 veth1
192.168.3.0 * 255.255.255.0 U 0 0 0 br0
#从这里也可以看出，由于原来的默认路由走的是eth0，所以当eth0的IP被删除之后，
#默认路由不见了，想要连接192.168.3.0/24以外的网段的话，需要手动将默认网关加回来#添加默认网关，然后再ping外网成功
dev@debian:~$ sudo ip route add default via 192.168.3.1
dev@debian:~$ ping -c 1 baidu.com
PING baidu.com (111.13.101.208) 56(84) bytes of data.
64 bytes from 111.13.101.208: icmp_seq=1 ttl=51 time=30.6 ms--- baidu.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 30.690/30.690/30.690/0.000 ms
经过上面一系列的操作后，网络变成了这个样子：
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Network Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ |
|.........................|...........................|..........|
| ↓ ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | | | .3.101 | | | | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 |<--->| br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+↓Physical Network
上面的操作中有几点需要注意：
- 如果是在虚拟机上做上述操作，记得打开网卡的混杂模式（不是在Linux里面，而是在虚拟机的配置上面，如VirtualBox上相应虚拟机的网卡配置项里面），不然veth1的网络会不通，因为eth0不在混杂模式的话，会丢掉目的mac地址是veth1的数据包
- 上面虽然通了，但由于Linux下arp的特性，当协议栈收到外面的arp请求时，不管是问101还是102，都会回复两个arp应答，分别包含br0和veth1的mac地址，也即Linux觉得外面发给101和102的数据包从br0和veth1进协议栈都一样，没有区别。由于回复了两个arp应答，而外面的设备只会用其中的一个，并且具体用哪个会随着时间发生变化，于是导致一个问题，就是外面回复给102的数据包可能从101的br0上进来，即通过102 ping外面时，可能在veth1抓不到回复包，而在br0上能抓到回复包。说明数据流在交换机那层没有完全的隔离开，br0和veth1会收到对方的IP应答包。为了解决上述问题，可以配置rp_filter,arp_filter, arp_ignore, arp_announce等参数，但不建议这么做，容易出错，调试比较麻烦。
- 在无线网络环境中，情况会变得比较复杂，因为无线网络需要登录，登陆后无线路由器只认一个mac地址，所有从这台机器出去的mac地址都必须是那一个，于是通过无线网卡上网的机器上的所有虚拟机想要上网的话，都必须依赖虚拟机管理软件（如VirtualBox）将每个虚拟机的网卡mac地址转成出口的mac地址（即无线网卡的mac地址），数据包回来的时候还要转回来，所以如果一个IP有两个ARP应答包的话，有可能导致mac地址的转换有问题，导致网络不通，或者有时通有时不通。解决办法就是将连接进br0的所有设备的mac地址都改成和eth0一样的mac地址，因为eth0的mac地址会被虚拟机正常的做转换。在上面的例子中，执行下面的命令即可：
dev@debian:~$ sudo ip link set dev veth1 down
#08:00:27:3b:0d:b9是eth0的mac地址
dev@debian:~$ sudo ip link set dev veth1 address 08:00:27:3b:0d:b9
dev@debian:~$ sudo ip link set dev veth1 up
bridge必须要配置IP吗？
在我们常见的物理交换机中，有可以配置IP和不能配置IP两种，不能配置IP的交换机一般通过com口连上去做配置（更简单的交换机连com口的没有，不支持任何配置），而能配置IP的交换机可以在配置好IP之后，通过该IP远程连接上去做配置，从而更方便。
bridge就属于后一种交换机，自带虚拟网卡，可以配置IP，该虚拟网卡一端连在bridge上，另一端跟协议栈相连。和物理交换机一样，bridge的工作不依赖于该虚拟网卡，但bridge工作不代表机器能连上网，要看组网方式。
删除br0上的IP:
dev@debian:~$ sudo ip addr del 192.168.3.101/24 dev br0
于是网络变成了这样子，相当于br0的一个端口通过eth0连着交换机，另一个端口通过veth0连着veth1：
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Network Protocol Stack | |
| +------------------------------------------------+ |
| ↑ |
|.....................................................|..........|
| ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | | | | | | | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 |<--->| br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+↓Physical Network
ping网关成功，说明这种情况下br0不配置IP对通信没有影响，数据包还能从veth1出去：
dev@debian:~$ ping -c 1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=1.24 ms--- 192.168.3.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.242/1.242/1.242/0.000 ms
上面如果没有veth0和veth1的话，删除br0上的IP后，网络将会不通，因为没有设备和协议栈完全相连
bridge常用场景
Bridge 设备通常就是结合 tap/tun、veth-pair 设备用于虚拟机、容器网络里面。这两种网络，在数据传输流程上还有些许不同，我们简单来看下：
首先是虚拟机网络，虚拟机一般通过 tap/tun 设备将虚拟机网卡同宿主机里的 Bridge 连接起来，完成同主机和跨主机的通信。如下图所示：
虚拟机发出的数据包通过 tap 设备先到达 br0，然后经过 eth0 发送到物理网络中，数据包不需要经过主机的的协议栈，效率是比较高的。
其次是容器网络（容器网络有多种引申的形式，这里我们只说 Bridge 网络），容器网络和虚拟机网络类似，不过一般是使用 veth-pair 来连接容器和主机，因为在主机看来，容器就是一个个被隔离的 namespace，用 veth-pair 更有优势。如下图所示：
容器的 Bridge 网络通常配置成内网形式，要出外网需要走 NAT，所以它的数据传输不像虚拟机的桥接形式可以直接跨过协议栈，而是必须经过协议栈，通过 NAT 和 ip_forward 功能从物理网卡转发出去，因此，从性能上看，Bridge 网络虚拟机要优于容器。
总结
Linux Bridge 是虚拟交换机，功能和物理交换机一样，用于连接虚拟机和容器。
虚拟机网络和容器网络的区别。
Bridge 是偏低级的工具，更高级的工具是 Open vSwitch，这个工具后面再详说。
原文链接：https://segmentfault.com/a/1190000009491002
linux虚拟网络设备之bridge(桥)（三）相关推荐
- Linux 虚拟网络设备
一.tun/tap(虚拟网卡) TUN/TAP设备浅析(一) – 原理浅析 - 简书 (jianshu.com) (3条消息) Linux-虚拟网络设备-tun/tap_sld880311的专栏-CS ...
- Linux - 虚拟网络设备 - bridge，veth，namespace
引用 轻松理解 Docker 网络虚拟化基础之网络 namespace! 轻松理解 Docker 网络虚拟化基础之 veth 设备! 深入理解 Linux 上软件实现的"交换机" ...
- 网络设备中的linux,理解linux虚拟网络设备veth
原标题:理解linux虚拟网络设备veth 前面介绍了linux network namespace,接着介绍一下如何让一个独立的网络命名空间和主机的网络互通,这里我们需要用到linux虚拟网络设备v ...
- linux 虚拟网络设备详解（四）
Linux 抽象网络设备简介 和磁盘设备类似,Linux 用户想要使用网络功能,不能通过直接操作硬件完成,而需要直接或间接的操作一个 Linux 为我们抽象出来的设备,既通用的 Linux 网络设备来 ...
- Linux 虚拟网络设备 tun/tap veth pair
Linux 虚拟网络设备 tun/tap veth pair 本篇主要介绍一下 linux 下面的 虚拟网络设备 tun/tap veth pair 随着容器逐步取代虚拟机,成为云基础架构的标准,然而 ...
- linux虚拟网络设备--虚拟机网卡和linux bridge上tap设备的关系（七）
1. 虚拟机进程 使用ps –ef |grepkvm可以看到虚拟机进程信息如下: /usr/libexec/qemu-kvm -nameinstance-0000001d -S -machine pc ...
- Linux 虚拟网络设备详解之 Bridge 网桥
Bridge 是什么 同 tap/tun.veth-pair 一样,Bridge 也是一种虚拟网络设备,所以具备虚拟网络设备的所有特性,比如可以配置 IP.MAC 等. 除此之外,Bridge 还是一 ...
- 理解linux虚拟网络设备bridge
上一节我们介绍了Linux veth设备,知道了如何把多个彼此隔离的网络命名空间(下面开始简称NS)与主机通过VETH连接起来,并且多个NS间也能相互通信,在这一节我们将介绍另一种方式,用linux ...
- linux虚拟网络设备--内核网桥的实现分析（六）
一.Linux内核网桥的实现分析 Linux 内核分别在2.2 和 2.4内核中实现了网桥.但是2.2 内核和 2.4内核的实现有很大的区别,2.4中的实现几乎是全部重写了所有的实现代码.本文以2.4 ...
最新文章
- 收藏 | 各种 Optimizer 梯度下降优化算法回顾和总结
- 八月25日8点半服务器维修,三国乱世8月25日合区维护公告
- 运放的主要参数详细介绍
- （二）注册服务提供者
- 数字逻辑对偶式_数字电子技术实验——组合逻辑电路的设计
- GPU Pro 2 ------ Volume Decals
- Golang sort 包使用
- 【BZOJ3675】【Apio2014】序列分割
- jupyter notebook安装后无法连接到ubuntu gpu环境
- Nginx服务器中的Socket切分,需要的朋友可以参考下
- 军用计算机通用规范测试试验,军用装备环境可靠性试验项目表
- 自己动手 DIY 一个读写200MB/s 的高速 U 盘
- 五招防止QQ密码被盗
- （三）SGE 部署 SGE
- vscode运行cpp文件：检测到 #include 错误。请更新 includePath。已为此翻译单元(E:\C++ Code\test1\test1\test1.cpp)禁用波形曲线。
- 阿里云ACP考试模拟试题（2）
- 《5G时代：生活方式和商业模式的大变革》读书笔记和总结
- 【IntelliJ IDEA】UTF-8编码下\u7528\u6237转换为中文汉字，\u9489\u9489\u81EA\u5B9A\u4E49\（Unicode字符与中文的相互转化）
- 原始（Primitive）类型
- if语句和switch语句
热门文章
- 自学python方法-零基础初学Python人工智能的四种学习方法
- 学习python好学吗-零基础学python难吗？好学吗？
- python中文件读写位置的作用-文件操作，读，写，指定位置
- python电脑配置苹果笔记本-tensorflow学习笔记1——mac开发环境配置
- python就业方向及工资-Python的就业的方向和前景
- python自动化办公pdf-基于python实现自动化办公学习笔记
- 零基础自学python的建议-零基础学python是学2还是3好
- python入门基础代码图-Python Matplotlib绘图基础知识代码解析
- Handler Bundle Runnable
- 20、Basic Shell_for_while_grep_find