Linux内核网络设备——bridge设备

和前面的文章一样,这次我们来一起讨论下bridge设备的数据走向。以下的实验简单,可以帮助linux技术初学者入门、理解。

往期回顾:
Linux 内核网络设备——vEth 设备和 network namespace 初步

Linux内核网络设备——tun、tap设备

Linux内核中的bridge设备

1. bridge设备介绍:

1.1 bridge设备也是一种虚拟的网络设备,所以具有网络设备的特性,bridge设备是一种纯软件实现的虚拟交换机,所以和物理的交换机有着类似的功能(mac地址学习、stp、fdb等)

1.2 bridge设备既可以配置ip地址也可以配置mac地址,可以实现交换机的二层转发。

1.3 bridge设备有多个端口,我们可以将tap设备、veth设备attach到bridge设备,我们可以想象成是交换机上的各种端口。

2. bridge实验:

2.1 我们将在ubuntu16.04上进行实验(之前在Centos7上出现了icmp报文在协议栈icmp_rcv丢包的情况,导致ping失败,但实际是抓到了包、也关闭了iptables的过滤,折腾了几天,最后换成ubuntu就没有这个情况)

2.2 拓扑环境介绍:

2.2.1在系统中创建一个名为br0的bridge设备,如图2-2-1:

图2-2-1

2.2.2 当我们创建br0设备时,它是一个独立的网络设备,可以看成是一端连接协议栈,然后br0没有任何端口,就像NF没有任何板卡,纯属是一个二层设备,拓扑如图2-2-2,这里假设ens是我们ubuntu的物理网卡,IP地址是192.168.15.131,网关是192.168.15.2:

图2-2-2

2.3 将bridge和veth pair一端相连

2.3.1创建veth pair,并配置上ip,如图2-3-1:

图2-3-1

2.3.2 将veth0 attached到br0,如图2-3-2-a,这就好比我们在交换机上加入了一块板卡(1个端口),这时候ubuntu上的而网络环境变为图2-3-2-b(为了画图方便,省略了IP地址前面的192.168,比如.15.111就表示192.168.15.111/24):

图2-3-2-a

图2-3-2-b

2.3.3 br0和veth0相连之后,发生了几个变化:

* br0和veth0之间是双向通道,br0可以把数据从veth0转发出去,也可以从veth0收包进来

*协议栈和veth0之间成了单向通道,协议栈可以将数据发给veth0,但是veth0从veth1收到的包会转发给br0进行处理,而不会转发给协议栈,br0处理完后才会转发给其他端口

* br0的mac地址变成了veth0的mac地址,如图2-3-3:

图2-3-3

2.3.4 校验数据收发

* 通过veth0去ping veth1(在这之前先设置本地接口arp响应相关的内核参数,如图2-3-4-a),如图2-3-4-b,ping失败:

图2-3-4-a

图2-3-4-b

*在br0上抓包,如图2-3-4-c,说明在br0收到arp响应:

图2-3-4-c

*在veth1上抓到双向的arp报文,如图2-3-4-d:

图2-3-4-d

*在veth0上抓到双向arp报文,如图2-3-4-e:

图2-3-4-f

*说明数据走向符合2-3-2-b描述的数据走向

2.4 给br0配置ip

2.4.1删除veth0的ip,给br0配置ip,如图2-4-1:

图2-4-1

2.4.2ubuntu上的网络拓扑如图2-4-2:

图2-4-2

2.4.3其实veth0和协议栈之间还是有联系的,但由于veth0没有配置IP,所以协议栈在路由的时候不会将数据包发给veth0,就算强制要求数据包通过veth0发送出去,但由于veth0从另一端收到的数据包只会给br0,所以协议栈还是没法收到相应的arp应答包,导致通信失败。这里为了表达更直观,将协议栈和veth0之间的联系去掉了,veth0已经attach到br上

2.4.4 这次通过br0去ping veth1,结果如图2-4-4:

图2-4-4

2.4.5注意:icmp响应仍然是发给lo设备的,因为192.168.15.111是本地网络设备的地址,所以会发给lo设备(在以后的文章中会加入策略路由的讨论)如图2-4-5:

图2-4-5

2.4.6 所以数据收发符合图2-4-2的描述(因为开启了arp相关的内核参数,arp响应的走向是满足的,icmp的响应也可以通过策略路由的调整满足图2-4-2的走向)

2.5 将物理网卡attach到br0上

2.5.1添加ens33到br0,如图2-5-1-a,且br0的mac变成了ens33的mac,如图2-5-1-b:

图2-5-1-a

图2-5-1-b

2.5.2 bridge设备不管成员设备是虚拟设备还是虚拟设备,本质上都是在内核中创建的net_device

2.5.3 这是通过ens33去ping网关已经不管用了,如图2-5-3:

图2-5-3

2.5.4 此时arp响应转发给了br0设备,如图2-5-4:

图2-5-4

2.5.5 此时通过veth1、br0都能ping网关,因为arp响应发给了br0设备,如图2-5-5-a、2-5-5-b:

图2-5-5-a

图2-5-5-b

2.5.6 此时ens33的ip已经没有什么作用了,这里我们将他的ip删除,如图2-5-6-a,修改过后ubuntu的网络拓扑如图2-5-6-b(192.168.15.100这个ip其实可以看成是协议栈中有个接口连接着br0,这个ip可以看成是那个接口的):

如图2-5-6-a

图2-5-6-b

2.6 将bridge设备的ip删掉

2.6.1删去br0的ip,如图2-6-1:

图2-6-1

2.6.2修改过的ubuntu的网络拓扑为图2-6-2:

图2-6-2

2.6.3 此时ping网关仍然成功,如图2-6-3:

图2-6-3

3. Bridge设备的常用场景

3.1 虚拟机,如图3-1(摘自网络),虚拟机通过tun/tap或者其它类似的虚拟网络设备,将虚拟机内的网卡同br0连接起来,这样就达到和真实交换机一样的效果,虚拟机发出去的数据包先到达br0,然后由br0交给eth0发送出去,数据包都不需要经过host机器的协议栈,效率高。

图3-1

3.2 docker,如图3-2(摘自网络),由于容器运行在自己单独的network namespace里面,所以都有自己单独的协议栈,情况和上面的虚拟机差不多,但它采用了另一种方式来和外界通信

如图3-2

3.2.1 容器中配置网关为.9.1,发出去的数据包先到达br0,然后交给host机器的协议栈,由于目的IP是外网IP,且host机器开启了IP forward功能,于是数据包会通过eth0发送出去,由于.9.1是内网IP,所以一般发出去之前会先做NAT转换(NAT转换和IP forward功能都需要自己配置)。由于要经过host机器的协议栈,并且还要做NAT转换,所以性能没有上面虚拟机那种方案好,优点是容器处于内网中,安全性相对要高点。(由于数据包统一由IP层从eth0转发出去,所以不存在mac地址的问题,在无线网络环境下也工作良好)

 


如有意成为绿盟科技博客作者,欢迎进入作者群讨论!

绿盟科技博客作者QQ群:695158981

 

 

 

 

 

绿盟科技博客作者微信群:

发表评论