什么是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
我們先創(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í)際功能,如下圖所示:
這里假設(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è)樣子:
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失?。?/p>
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ò)變成了這樣子:
其實(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è)樣子:
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:
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é)議棧,效率高。
docker
由于容器運(yùn)行在自己?jiǎn)为?dú)的network namespace里面,所以都有自己?jiǎn)为?dú)的協(xié)議棧,情況和上面的虛擬機(jī)差不多,但它采用了另一種方式來(lái)和外界通信:
容器中配置網(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)題