Linux 虛擬網(wǎng)絡(luò)設(shè)備之 bridge
點(diǎn)擊上方 
藍(lán)字關(guān)注我們
本文將通過(guò)實(shí)際的例子來(lái)一步一步解釋bridge是如何工作的。
什么是bridge？
首先，bridge是一個(gè)虛擬網(wǎng)絡(luò)設(shè)備，所以具有網(wǎng)絡(luò)設(shè)備的特征，可以配置IP、MAC地址等；其次，bridge是一個(gè)虛擬交換機(jī)，和物理交換機(jī)有類似的功能。
對(duì)于普通的網(wǎng)絡(luò)設(shè)備來(lái)說(shuō)，只有兩端，從一端進(jìn)來(lái)的數(shù)據(jù)會(huì)從另一端出去，如物理網(wǎng)卡從外面網(wǎng)絡(luò)中收到的數(shù)據(jù)會(huì)轉(zhuǎn)發(fā)給內(nèi)核協(xié)議棧，而從協(xié)議棧過(guò)來(lái)的數(shù)據(jù)會(huì)轉(zhuǎn)發(fā)到外面的物理網(wǎng)絡(luò)中。
而bridge不同，bridge有多個(gè)端口，數(shù)據(jù)可以從任何端口進(jìn)來(lái)，進(jìn)來(lái)之后從哪個(gè)口出去和物理交換機(jī)的原理差不多，要看mac地址。
創(chuàng)建bridge
我們先用iproute2創(chuàng)建一個(gè)bridge：
dev@debian:~$ sudo ip link add name br0 type bridge
dev@debian:~$ sudo ip link set br0 up
當(dāng)剛創(chuàng)建一個(gè)bridge時(shí)，它是一個(gè)獨(dú)立的網(wǎng)絡(luò)設(shè)備，只有一個(gè)端口連著協(xié)議棧，其它的端口啥都沒(méi)連，這樣的bridge沒(méi)有任何實(shí)際功能，如下圖所示：
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Newwork Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ |
|..............|................................|................|
| ↓ ↓ |
| +----------+ +------------+ |
| | eth0 | | br0 | |
| +----------+ +------------+ |
| 192.168.3.21 ↑ |
| | |
| | |
+--------------|-------------------------------------------------+
↓
Physical Network
?這里假設(shè)eth0是我們的物理網(wǎng)卡，IP地址是192.168.3.21，網(wǎng)關(guān)是192.168.3.1
將bridge和veth設(shè)備相連
創(chuàng)建一對(duì)veth設(shè)備，并配置上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
#通過(guò)bridge link命令可以看到br0上連接了哪些設(shè)備
dev@debian:~$ sudo bridge link
6: veth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
這時(shí)候，網(wǎng)絡(luò)就變成了這個(gè)樣子:
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Newwork Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ | ↑ |
|............|............|..............|............|..........|
| ↓ ↓ ↓ ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | .3.21| | | | .3.101| | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 | | br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+
↓
Physical Network
?這里為了畫(huà)圖方便，省略了IP地址前面的192.168，比如.3.21就表示192.168.3.21
br0和veth0相連之后，發(fā)生了幾個(gè)變化：
br0和veth0之間連接起來(lái)了，并且是雙向的通道 協(xié)議棧和veth0之間變成了單通道，協(xié)議棧能發(fā)數(shù)據(jù)給veth0，但veth0從外面收到的數(shù)據(jù)不會(huì)轉(zhuǎn)發(fā)給協(xié)議棧 br0的mac地址變成了veth0的mac地址
相當(dāng)于bridge在veth0和協(xié)議棧之間插了一腳，在veth0上面做了點(diǎn)小動(dòng)作，將veth0本來(lái)要轉(zhuǎn)發(fā)給協(xié)議棧的數(shù)據(jù)給攔截了，全部轉(zhuǎn)發(fā)給bridge了，同時(shí)bridge也可以向veth0發(fā)數(shù)據(jù)。
下面來(lái)檢驗(yàn)一下是不是這樣的：
通過(guò)veth0 ping veth1失?。?/span>
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緩存里面沒(méi)有veth1的mac地址，所以ping之前先發(fā)arp請(qǐng)求
#從veth1上抓包來(lái)看，veth1收到了arp請(qǐng)求，并且返回了應(yīng)答
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上抓包來(lái)看，數(shù)據(jù)包也發(fā)出去了，并且也收到了返回
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上的數(shù)據(jù)包，發(fā)現(xiàn)只有應(yīng)答
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
從上面的抓包可以看出，去和回來(lái)的流程都沒(méi)有問(wèn)題，問(wèn)題就出在veth0收到應(yīng)答包后沒(méi)有給協(xié)議棧，而是給了br0，于是協(xié)議棧得不到veth1的mac地址，從而通信失敗。
給bridge配上IP
通過(guò)上面的分析可以看出，給veth0配置IP沒(méi)有意義，因?yàn)榫退銋f(xié)議棧傳數(shù)據(jù)包給veth0，應(yīng)答包也回不來(lái)。這里我們就將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
于是網(wǎng)絡(luò)變成了這樣子：
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Newwork Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ ↑ |
|............|............|...........................|..........|
| ↓ ↓ ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | .3.21| | .3.101 | | | | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 | | br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+
↓
Physical Network
?其實(shí)veth0和協(xié)議棧之間還是有聯(lián)系的，但由于veth0沒(méi)有配置IP，所以協(xié)議棧在路由的時(shí)候不會(huì)將數(shù)據(jù)包發(fā)給veth0，就算強(qiáng)制要求數(shù)據(jù)包通過(guò)veth0發(fā)送出去，但由于veth0從另一端收到的數(shù)據(jù)包只會(huì)給br0，所以協(xié)議棧還是沒(méi)法收到相應(yīng)的arp應(yīng)答包，導(dǎo)致通信失敗。這里為了表達(dá)更直觀，將協(xié)議棧和veth0之間的聯(lián)系去掉了，veth0相當(dāng)于一根網(wǎng)線。
再通過(guò)br0 ping一下veth1，結(jié)果成功
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網(wǎng)關(guān)還是失敗，因?yàn)檫@個(gè)bridge上只有兩個(gè)網(wǎng)絡(luò)設(shè)備，分別是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
將物理網(wǎng)卡添加到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根本不區(qū)分接入進(jìn)來(lái)的是物理設(shè)備還是虛擬設(shè)備，對(duì)它來(lái)說(shuō)都一樣的，都是網(wǎng)絡(luò)設(shè)備，所以當(dāng)eth0加入br0之后，落得和上面veth0一樣的下場(chǎng)，從外面網(wǎng)絡(luò)收到的數(shù)據(jù)包將無(wú)條件的轉(zhuǎn)發(fā)給br0，自己變成了一根網(wǎng)線。
這時(shí)通過(guò)eth0來(lái)ping網(wǎng)關(guān)失敗，但由于br0通過(guò)eth0這根網(wǎng)線連上了外面的物理交換機(jī)，所以連在br0上的設(shè)備都能ping通網(wǎng)關(guān)，這里連上的設(shè)備就是veth1和br0自己，veth1是通過(guò)veth0這根網(wǎng)線連上去的，而br0可以理解為自己有一塊自帶的網(wǎng)卡。
#通過(guò)eth0來(lái)ping網(wǎng)關(guān)失敗
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
#通過(guò)br0來(lái)ping網(wǎng)關(guān)成功
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
#通過(guò)veth1來(lái)ping網(wǎng)關(guān)成功
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已經(jīng)變成了和網(wǎng)線差不多的功能，所以在eth0上配置IP已經(jīng)沒(méi)有什么意義了，并且還會(huì)影響協(xié)議棧的路由選擇，比如如果上面ping的時(shí)候不指定網(wǎng)卡的話，協(xié)議棧有可能優(yōu)先選擇eth0，導(dǎo)致ping不通，所以這里需要將eth0上的IP去掉。
#在本人的測(cè)試機(jī)器上，由于eth0上有IP，
#訪問(wèn)192.168.3.0/24網(wǎng)段時(shí)，會(huì)優(yōu)先選擇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已結(jié)接入了br0，所有它收到的數(shù)據(jù)包都會(huì)轉(zhuǎn)發(fā)給br0，
#于是協(xié)議棧收不到arp應(yīng)答包，導(dǎo)致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
#這是因?yàn)閑th0沒(méi)有IP之后，路由表里面就沒(méi)有它了，于是數(shù)據(jù)包會(huì)從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
#從這里也可以看出，由于原來(lái)的默認(rèn)路由走的是eth0，所以當(dāng)eth0的IP被刪除之后，
#默認(rèn)路由不見(jiàn)了，想要連接192.168.3.0/24以外的網(wǎng)段的話，需要手動(dòng)將默認(rèn)網(wǎng)關(guān)加回來(lái)
#添加默認(rèn)網(wǎng)關(guān)，然后再ping外網(wǎng)成功
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
經(jīng)過(guò)上面一系列的操作后，網(wǎng)絡(luò)變成了這個(gè)樣子：
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Newwork Protocol Stack | |
| +------------------------------------------------+ |
| ↑ ↑ |
|.........................|...........................|..........|
| ↓ ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | | | .3.101 | | | | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 |<--->| br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+
↓
Physical Network
上面的操作中有幾點(diǎn)需要注意：
如果是在虛擬機(jī)上做上述操作，記得打開(kāi)網(wǎng)卡的混雜模式（不是在Linux里面，而是在虛擬機(jī)的配置上面，如VirtualBox上相應(yīng)虛擬機(jī)的網(wǎng)卡配置項(xiàng)里面），不然veth1的網(wǎng)絡(luò)會(huì)不通，因?yàn)閑th0不在混雜模式的話，會(huì)丟掉目的mac地址是veth1的數(shù)據(jù)包
上面雖然通了，但由于Linux下arp的特性，當(dāng)協(xié)議棧收到外面的arp請(qǐng)求時(shí)，不管是問(wèn)101還是102，都會(huì)回復(fù)兩個(gè)arp應(yīng)答，分別包含br0和veth1的mac地址，也即Linux覺(jué)得外面發(fā)給101和102的數(shù)據(jù)包從br0和veth1進(jìn)協(xié)議棧都一樣，沒(méi)有區(qū)別。由于回復(fù)了兩個(gè)arp應(yīng)答，而外面的設(shè)備只會(huì)用其中的一個(gè)，并且具體用哪個(gè)會(huì)隨著時(shí)間發(fā)生變化，于是導(dǎo)致一個(gè)問(wèn)題，就是外面回復(fù)給102的數(shù)據(jù)包可能從101的br0上進(jìn)來(lái)，即通過(guò)102 ping外面時(shí)，可能在veth1抓不到回復(fù)包，而在br0上能抓到回復(fù)包。說(shuō)明數(shù)據(jù)流在交換機(jī)那層沒(méi)有完全的隔離開(kāi)，br0和veth1會(huì)收到對(duì)方的IP應(yīng)答包。為了解決上述問(wèn)題，可以配置rp_filter, arp_filter, arp_ignore, arp_announce等參數(shù)，但不建議這么做，容易出錯(cuò)，調(diào)試比較麻煩。
在無(wú)線網(wǎng)絡(luò)環(huán)境中，情況會(huì)變得比較復(fù)雜，因?yàn)闊o(wú)線網(wǎng)絡(luò)需要登錄，登陸后無(wú)線路由器只認(rèn)一個(gè)mac地址，所有從這臺(tái)機(jī)器出去的mac地址都必須是那一個(gè)，于是通過(guò)無(wú)線網(wǎng)卡上網(wǎng)的機(jī)器上的所有虛擬機(jī)想要上網(wǎng)的話，都必須依賴虛擬機(jī)管理軟件（如VirtualBox）將每個(gè)虛擬機(jī)的網(wǎng)卡mac地址轉(zhuǎn)成出口的mac地址（即無(wú)線網(wǎng)卡的mac地址），數(shù)據(jù)包回來(lái)的時(shí)候還要轉(zhuǎn)回來(lái)，所以如果一個(gè)IP有兩個(gè)ARP應(yīng)答包的話，有可能導(dǎo)致mac地址的轉(zhuǎn)換有問(wèn)題，導(dǎo)致網(wǎng)絡(luò)不通，或者有時(shí)通有時(shí)不通。解決辦法就是將連接進(jìn)br0的所有設(shè)備的mac地址都改成和eth0一樣的mac地址，因?yàn)閑th0的mac地址會(huì)被虛擬機(jī)正常的做轉(zhuǎn)換。在上面的例子中，執(zhí)行下面的命令即可：
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嗎？
在我們常見(jiàn)的物理交換機(jī)中，有可以配置IP和不能配置IP兩種，不能配置IP的交換機(jī)一般通過(guò)com口連上去做配置（更簡(jiǎn)單的交換機(jī)連com口的沒(méi)有，不支持任何配置），而能配置IP的交換機(jī)可以在配置好IP之后，通過(guò)該IP遠(yuǎn)程連接上去做配置，從而更方便。
bridge就屬于后一種交換機(jī)，自帶虛擬網(wǎng)卡，可以配置IP，該虛擬網(wǎng)卡一端連在bridge上，另一端跟協(xié)議棧相連。和物理交換機(jī)一樣，bridge的工作不依賴于該虛擬網(wǎng)卡，但bridge工作不代表機(jī)器能連上網(wǎng)，要看組網(wǎng)方式。
刪除br0上的IP:
dev@debian:~$ sudo ip addr del 192.168.3.101/24 dev br0
于是網(wǎng)絡(luò)變成了這樣子，相當(dāng)于br0的一個(gè)端口通過(guò)eth0連著交換機(jī)，另一個(gè)端口通過(guò)veth0連著veth1：
+----------------------------------------------------------------+
| |
| +------------------------------------------------+ |
| | Newwork Protocol Stack | |
| +------------------------------------------------+ |
| ↑ |
|.....................................................|..........|
| ↓ |
| +------+ +--------+ +-------+ +-------+ |
| | | | | | | | .3.102| |
| +------+ +--------+ +-------+ +-------+ |
| | eth0 |<--->| br0 |<--->| veth0 | | veth1 | |
| +------+ +--------+ +-------+ +-------+ |
| ↑ ↑ ↑ |
| | | | |
| | +------------+ |
| | |
+------------|---------------------------------------------------+
↓
Physical Network
ping網(wǎng)關(guān)成功，說(shuō)明這種情況下br0不配置IP對(duì)通信沒(méi)有影響，數(shù)據(jù)包還能從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
?上面如果沒(méi)有veth0和veth1的話，刪除br0上的IP后，網(wǎng)絡(luò)將會(huì)不通，因?yàn)闆](méi)有設(shè)備和協(xié)議棧完全相連
bridge常用場(chǎng)景
上面通過(guò)例子展示了bridge的功能，但例子中的那種部署方式?jīng)]有什么實(shí)際用途，還不如在一個(gè)網(wǎng)卡上配置多個(gè)IP地址來(lái)的直接。這里來(lái)介紹兩種常見(jiàn)的部署方式。
虛擬機(jī)
虛擬機(jī)通過(guò)tun/tap或者其它類似的虛擬網(wǎng)絡(luò)設(shè)備，將虛擬機(jī)內(nèi)的網(wǎng)卡同br0連接起來(lái)，這樣就達(dá)到和真實(shí)交換機(jī)一樣的效果，虛擬機(jī)發(fā)出去的數(shù)據(jù)包先到達(dá)br0，然后由br0交給eth0發(fā)送出去，數(shù)據(jù)包都不需要經(jīng)過(guò)host機(jī)器的協(xié)議棧，效率高。
+----------------------------------------------------------------+-----------------------------------------+-----------------------------------------+
| Host | VirtualMachine1 | VirtualMachine2 |
| | | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| | Newwork Protocol Stack | | | Newwork Protocol Stack | | | Newwork Protocol Stack | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| ↑ | ↑ | ↑ |
|..........................|.....................................|...................|.....................|....................|....................|
| ↓ | ↓ | ↓ |
| +--------+ | +-------+ | +-------+ |
| | .3.101 | | | .3.102| | | .3.103| |
| +------+ +--------+ +-------+ | +-------+ | +-------+ |
| | eth0 |<--->| br0 |<--->|tun/tap| | | eth0 | | | eth0 | |
| +------+ +--------+ +-------+ | +-------+ | +-------+ |
| ↑ ↑ ↑ | ↑ | ↑ |
| | | +-------------------------------------------+ | | |
| | ↓ | | | |
| | +-------+ | | | |
| | |tun/tap| | | | |
| | +-------+ | | | |
| | ↑ | | | |
| | +-------------------------------------------------------------------------------|--------------------+ |
| | | | |
| | | | |
| | | | |
+------------|---------------------------------------------------+-----------------------------------------+-----------------------------------------+
↓
Physical Network (192.168.3.0/24)
docker
由于容器運(yùn)行在自己?jiǎn)为?dú)的network namespace里面，所以都有自己?jiǎn)为?dú)的協(xié)議棧，情況和上面的虛擬機(jī)差不多，但它采用了另一種方式來(lái)和外界通信：
+----------------------------------------------------------------+-----------------------------------------+-----------------------------------------+
| Host | Container 1 | Container 2 |
| | | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| | Newwork Protocol Stack | | | Newwork Protocol Stack | | | Newwork Protocol Stack | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| ↑ ↑ | ↑ | ↑ |
|............|.............|.....................................|...................|.....................|....................|....................|
| ↓ ↓ | ↓ | ↓ |
| +------+ +--------+ | +-------+ | +-------+ |
| |.3.101| | .9.1 | | | .9.2 | | | .9.3 | |
| +------+ +--------+ +-------+ | +-------+ | +-------+ |
| | eth0 | | br0 |<--->| veth | | | eth0 | | | eth0 | |
| +------+ +--------+ +-------+ | +-------+ | +-------+ |
| ↑ ↑ ↑ | ↑ | ↑ |
| | | +-------------------------------------------+ | | |
| | ↓ | | | |
| | +-------+ | | | |
| | | veth | | | | |
| | +-------+ | | | |
| | ↑ | | | |
| | +-------------------------------------------------------------------------------|--------------------+ |
| | | | |
| | | | |
| | | | |
+------------|---------------------------------------------------+-----------------------------------------+-----------------------------------------+
↓
Physical Network (192.168.3.0/24)
容器中配置網(wǎng)關(guān)為.9.1，發(fā)出去的數(shù)據(jù)包先到達(dá)br0，然后交給host機(jī)器的協(xié)議棧，由于目的IP是外網(wǎng)IP，且host機(jī)器開(kāi)啟了IP forward功能，于是數(shù)據(jù)包會(huì)通過(guò)eth0發(fā)送出去，由于.9.1是內(nèi)網(wǎng)IP，所以一般發(fā)出去之前會(huì)先做NAT轉(zhuǎn)換（NAT轉(zhuǎn)換和IP forward功能都需要自己配置）。由于要經(jīng)過(guò)host機(jī)器的協(xié)議棧，并且還要做NAT轉(zhuǎn)換，所以性能沒(méi)有上面虛擬機(jī)那種方案好，優(yōu)點(diǎn)是容器處于內(nèi)網(wǎng)中，安全性相對(duì)要高點(diǎn)。（由于數(shù)據(jù)包統(tǒng)一由IP層從eth0轉(zhuǎn)發(fā)出去，所以不存在mac地址的問(wèn)題，在無(wú)線網(wǎng)絡(luò)環(huán)境下也工作良好）
?上面兩種部署方案中，同一網(wǎng)段的每個(gè)網(wǎng)卡都有自己?jiǎn)为?dú)的協(xié)議棧，所以不存在上面說(shuō)的多個(gè)ARP的問(wèn)題
鏈接：https://segmentfault.com/a/1190000009491002
有收獲，點(diǎn)個(gè)在看 