neutron: linuxbridge 架构解析

现在openstack官方社区构筑guide里面，默认使用linuxbridge（以下简称lb）替代openvswitch（以下简称ovs）来作为ml2的plugin。社区对于lb的分析很详细：

https://docs.openstack.org/ocata/networking-guide/deploy-lb-selfservice.html

但是却不是很好由浅入深的理解（适合老鸟回忆）。这里我按照各个场景重新分析一遍。

P.S. 以下场景中，tenant network 为 vxlan，provider network为flat

1. instance 以dhcp获取ip （tenant network 以vxlan为例）

在正式分析之前，我们先了解下物理机与一次dhcp server的通信交互流程：

1. 物理机器通过eth0发送数据包packet1到交换机端口if1

2. 交换机把packet1从if1转发到if2  （同一台交换机上各个端口在默认情况下可以互相转发。至于配置vlan等情况限制转发，在此不做考虑）

3. 交换机把packet1从if2发送到dhcp server的eth0

4. dhcp server把对物理机器的回复数据包packet2通过eth0传送到交换机的if2端口

5. 交换机把packet2从if2端口转发到if1端口

6. 交换机把packet2从if1端口发送到物理机器的eth0

P.S. 其实真实情况下获取IP的交互流程比上述复杂的多，这里为了方便后续解析linuxbridge原理做了简化。

想学习dhcp server完整分配ip流程请参考网络其他资料。

理解了物理机和dhcp server通信原理后，再对比理解下instance在tenant network内与dnsmasq通信流程：

1. instance通过eth0发送数据包packet1到brq的tapA

2. brq把packet1从tapA转发到tapB  （同一台bridge上各个tapA设备在默认情况下可以互相转发。跟物理交换机功能相同）

3. brq把packet1从tapB发送到dnsmasq的eth0

4. dnsmasq把对instance的回复数据包packet2通过eth0传送到brq的tapB

5. brq把packet2从tapB转发到tapA

6. brq把packet2从tapA发送到instance的eth0

下面从真实openstack环境进行与上述图片的对比说明：

上图截取自compute节点。

圆圈中brq**开头的设备对应brq

圆圈中tap**开头的设备对应brq上的tapA

上图截取自controller节点

圆圈中brq**开头的设备对应brq

圆圈中tap**开头的设备对应brq上的tapB

讲解到这里：先解决几个可能的疑问：

①为啥controller和compute上都有brq？

答：如果大家仔细看，会发现截图中brq***中的数字序号是相同的：可以从逻辑上认为是同一个brq（截图中可以确认）。

②真实环境中有很多tap设备，如果寻找dnsmasq对应的那个tap设备？

答：有两种办法。

1） ip netns exec 命令进入dhcp的namespace后利用ip addr命令查看网卡名称：它跟tap***后面的名称一致。

2）  ip netns exec 命令进入dhcp的namespace后利用ethtool -S 网卡名称 查询index序号。该序号对应的tap设备就是dnsmasq对应的tap设备。

问题②需要一些tap/veth设备和namespace的知识，这里不详细赘述。