Linux 网络协议栈开发（四）—— 二层桥实现原理

（转自 http://blog.csdn.net/u010246947/article/details/18223263）

网桥原理：

    网桥工作在链路层，所以它是二层的东西，对于以太网来说网桥和二层网络设备交换机的工作方式几乎是一样的，每个交换机包含一系列以太网接口，交换机通过其内部的硬件交换芯片实现对这些以太网接口出入报文的二层接收转发及过滤等二层qos功能，网桥在功能上和交换机几乎是一样的，只不过它是由软件实现这些功能。

    下图是交换机和网桥的内部实现原理简图：

二层交换机内部实现简图

                          网桥内部实现简图
  

  如上图，可以把网桥本身看做一个二层交换机，该交换机下面有eth0、usb1、vlan2、wlan3共4个接口，每个网桥下可以有很多个接口，不考虑STP生成树协议的话，可以认为网桥下接口是由用户配置的，普遍用brctl应用程序工具生成网桥，并在每个网桥下增加和删除接口，brctl使用举例如下：

  初始情况下，没有网桥，由命令“brctl addbr br0”创建一个网桥br0，然后可以观察到创建了网桥br0，此时它底下还没有接口，然后由命令“brctl addif br0 XXX”在网桥br0下加入接口eth1、eth2，然后可以观察到网桥br0底下有这两个接口；同时网桥br0的MAC地址表还加入了两个静态的MAC地址，分别是接口eth1和eth2的MAC地址，这时如果从eth1接口进入属于网桥br0的报文，并且该报文的目的MAC地址与eth2接口的MAC地址相同，那么报文将被从eth2接口转发出去，并且会记录该报文的源MAC地址和进入接口eth1的对应关系作为网桥br0的一个动态MAC地址条目。

  再如，我们的网关设备做测试时，如需测试二层业务流性能，经常把wan接口和vlan1接口做桥接，然后即可打双向二层业务流，同样是通过网桥学习两个接口进入报文的源MAC地址和进入接口的对应关系，实现网桥的两个接口对打二层业务流，由此可见，这和二层交换机的MAC地址学习和转发的道理是一样的。

  此外，linux的网桥同样还实现了多种多样的报文处理功能，同样依托netfilter框架，通过不同的hook点挂载不同的包处理环节，其qos功能可以比二层交换机还要丰富。

1、linux的网桥实现：

1.1、涉及文件：

Linux网桥实现在代码树的net/bridge/目录下，主要文件如下：

l  br.c：网桥模块初始化；

l  br_device.c：网桥net_device的ops实现；

l  br_fdb.c：网桥的MAC地址表实现；

l  br_forward.c：网桥的报文转发逻辑实现；

l  br_if.c：网桥及桥端口的创建增删操作；

l  br_input.c：网桥的报文处理函数；

l  br_ioctl.c：网桥的用户ioctl接口；

l  br_netfilter.c：网桥的netfilter框架及默认挂载的hook；

l  br_netlink.c：网桥的netlink接口；

l  br_notify.c：网桥的内核通知链；

l  其余文件为网桥的STP协议相关和默认的netfilter处理函数实现；

1.2、重要数据结构：

1.2.1、网桥创建：

 我们知道linux内核协议栈的链路层中，任何一个收发实体都是以结构体net_device描述的，这一个个的收发实体可以是有实际物理设备支持的，如常见的以太网卡设备ethX、usb网卡设备、无线网卡设备等等，也可以是没有实际物理设备支持的虚拟网卡设备，如vlan接口、网桥接口，之所以这样做是因为在内核中对收发实体的一切处理逻辑都是统一的接口，事实上这体现的就是linux内核面向对象的重要思想。

 所以每一个网桥在linux内核中也都是以net_device结构体描述，不同的是网桥net_device的私货部分是结构体net_bridge，它描述了网桥与其他类型net_device诸如以太网卡设备、vlan接口等的区别，事实上不同类型的net_device，其区别主要是通过私货部分标识，对于网桥net_device它的私货就是结构体net_bridge，如下图：

  如不考虑STP生成树协议部分的内容，net_bridge结构最值得注意的字段如下：

1、dev：它标识该网桥自身的net_device，对于IP层及以上协议，链路层可见的是网桥，而不是网桥底下的接口，所以上层操作的net_device都是网桥的net_device；另外网桥自身的net_device也是区分不同网桥的依据，这些是该字段存在的重要意义；

2、ageing_time：动态MAC地址的老化时间；

3、stp_enabled：标识该网桥是否开启STP功能，默认为关闭，本文不讨论STP协议相关的内容；

  创建了一个网桥就如同创建了一个交换机，但此时这个“交换机”底下还没有接口

  用户应用程序(典型如brctl)创建网桥的过程如下：

  创建网桥的核心函数是br_add_bridge，它创建了网桥的net_device并将其注册进内核，注意用户创建网桥时只需传入网桥名称即可；

网桥net_device的私货是结构体net_bridge，new_bridge_dev函数对它进行初始化，主要内容包括：

创建了网桥自身的net_device并由私货回指(br->dev= dev)；

设置默认关闭STP协议(br->stp_enabled= BR_NO_STP)；

设置网桥的默认动态MAC地址老化时间为300秒(br->ageing_time= 300 * HZ)；

开启动态MAC地址老化定时器(br_stp_timer_init(br))；

1.2.2、网桥接口添加：

  创建网桥后，需要再加入接口，网桥的每一个接口在linux内核中以net_bridge_port结构体描述，在内核中称为桥端口，如下：

同样如果不考虑STP协议相关内容，只需关注如下字段：

1、br：标识该桥端口属于哪个网桥；

2、dev：标识该桥端口实际对应哪个接口；

3、state：标识该桥端口的状态，一般为BR_STATE_FORWARDING即转发；

  在创建好网桥后，应用程序通过网桥的ops在网桥中加入接口，过程如下：

 有了网桥，并在网桥下加入了接口，那么该网桥就可以发挥二层交换机的作用了。需要注意的问题如下：

1、同一个接口不能作为不同网桥的桥端口；

2、网桥下的桥端口，都必须是混杂模式，但网桥自身不一定是混杂模式，往往在有特殊需求时如需要抓包时，会把网桥自身接口设置为混杂模式，即网桥下所有桥端口接收到的报文都要送给本机一份；

3、每创建一个桥端口，都会把该桥端口对应接口的MAC地址作为静态MAC地址记录在所属网桥的MAC地址表中，静态MAC地址不会被老化，因为目的地址是该接口MAC地址，说明是送给该接口所在主机的报文即送本地的报文，所以不能老化掉这样的MAC地址；

4、网桥自身接口的mtu和MAC地址是其底下所有桥接口的mtu最小值和MAC地址最小值，都也可以由用户配置修改；

5、不考虑STP协议情况下，桥端口的状态是转发(BR_STATE_FORWARDING)，一般情况下不必考虑桥端口的其他状态；

2、网桥报文接收处理：

  前面已经提到，linux内核对于报文收发处理使用统一的接口，在报文接收处理中，都是由驱动层接收到报文后调用函数netif_receive_skb进入协议栈处理，网桥的处理入口函数为handle_bridge，实质处理函数是br_handle_frame，流程如下：

结合上图，网桥处理的重点如下：

1、需要进行桥接处理的报文，其输入接口必须属于某网桥；

2、暂不考虑STP协议报文的处理，对于上图重点关注“报文转发流程”框之后的内容；

3、桥接处理前会检查用户是否通过ebtables工具在链路层对报文进行过滤或其他处理，ebtables工具类似iptables工具，可以加不同的规则，区别在于它工作在链路层，这实现了类似二层交换机的qos功能；

4、每次报文处理都首先进行动态MAC地址的学习或更新老化时间；

5、对于某些操作，如对网桥进行抓包，这会使网桥自身接口被设置为混杂模式，这时必须把报文复制一份送至本地；

6、 组播/广播/未知单播报文会洪泛到每个桥端口，已知单播报文若目的端口为本机则送至本机，若非本机则从对应桥端口转发出去；可见网桥与二层交换机在单播和广播报文的转发方面是一样的，唯一区别在于组播报文的处理，在我们的网关设备上通过修改内核，是不允许组播报文在网桥上传播的；

3、网桥报文发送处理：

  前面一节中已经提到，网桥net_device的ops实现在内核的br_device.c文件中，如同网卡驱动一样，网桥作为一种特殊的网络设备，它也有它的ops方法集，linux已定义好它，如下图：

其中指定了网桥这种网络设备的发送方法为函数br_dev_xmit，即比如应用程序使用send函数族系统调用从网桥发送报文时，将最终调用br_dev_xmit函数，其处理逻辑依然遵循网桥原理或者说就是二层交换原理，已知单播报文即按MAC地址转发，广播/组播/未知单播报文洪泛到所有桥端口，处理流程如下：

4、网桥不同情况下的报文流向：

4.1、传入本机：

 切记这里的传入本机，并不一定是要传入本机传输层，而仅仅是意味着该报文的目的MAC地址是该网桥下某桥端口对应接口的MAC地址，即报文穿过网桥继续走本机协议栈进行进一步处理，如下图：

4.2、转发出去：

  转发最终均调用dev_queue_xmit，这和所有的报文发送的道理是一样的，需要注意的是转发接口的更换和网桥转发的两次netfilter，如下图：

4.3、传入本机后再从网桥转发：

  这个情况实际是7.2.4.1中后续可能发生情况的一种，即在路由判决后，该报文应从一个网桥接口转发，如下图：

同理，该报文也可在传入本机后再从某个其他接口转发，如从某个以太网卡接口、usb接口、wlan接口等等。