一，链路层

在报文接收方向上，网卡驱动把接收到的数据按照其对应的链路层协议(如以太网)组装成报文，然后把它上交给链路层，接口�.NETif_receive_skb，至此网卡驱动的任务就结束了，报文交给链路层处理；

在报文发送方向上，网卡驱动受链路层驱使，链路层告知其有报文要发送时，网卡驱动才开始工作，接口是dev_queue_xmit。

上面是链路层和网卡驱动层的接口，然而在链路层不一定是报文最终的归宿，从报文接收角度看，绝大多数报文都要最终给目的主机的应用层，协议报文会在不同协议所属层次终结，所以大多数报文都还要由链路层处理后(或不处理)再向上层转发，比如IP报文，在链路层由ip_rcv函数进入网络层处理，比如由应用程序通过原始套接字获取的报文将在链路层被直接送往socket层，比如arp协议报文会被送往arp模块去处理……

再从报文发送角度看，不同的处理模块，会通过其专有接口通知链路层要发送报文，比如对于网络层，通过ip_finish_output(最终是ip_finish_output2)告诉链路层要发送报文(事实上是经由邻居子系统模块实际发送，邻居子系统实现链路层和网络层的映射，可以认为属于链路层和网络层的中间层)，当然原始套接字的情况则比较简单，直接调用dev_queue_xmit通知网卡驱动，然而对于网桥、vlan子接口的收发，链路层的处理就显得极为必要，而从网络分层理论看，网桥、vlan，正是逻辑链路层的内容，这些都属于linux链路层的核心工作，典型的对于以太网的链路层，以太网类型、vlan、源目mac地址是链路层的协议字段。

此外，在链路层的无需三层协议转发的二层隧道转发方式，典型如按网络层IP地址转发的eoip(Ethernet over ip)，也是链路层的任务。

更多Linux内核视频教程文档资料免费领取后台私信【内核】自行获取。

 

从功能上看，链路层完成以下任务：

• 1、 实现与网卡驱动和协议栈上层的接口；
• 2、 实现网桥，即实现按MAC地址转发的二层交换机功能；
• 3、 实现vlan处理，实现带vlan报文的传输；
• 4、 实现邻居子系统，即实现链路层和网络层的映射；
• 5、 根据以太网类型，实现根据链路层协议类型收发报文；
• 6、实现二层隧道功能(典型如依托于网络层IP地址转发的eoip隧道)；

 

如上图，链路层由netif_receive_skb收到报文后，依次进行网桥处理、L2隧道处理、按以太网类型处理(事实上在按以太网类型处理前，还可能有其他处理)，网桥处理中会根据报文是否发给本机还是转发做不同的处理，发给本机将修改报文输入接口为桥端口并返回netif_receive_skb重新进协议栈处理，转发则直接调用dev_queue_xmit从对应接口发送；L2隧道处理则根据所属隧道的目的IP寻找路由，并根据路由结果指示的出接口转发报文；按以太网类型处理，就根据以太网类型调用在之前注册过的协议处理函数，如vlan报文调用vlan_skb_recv，IP报文调用ip_rcv，arp报文调用arp_rcv等等；

需要注意对于网桥和vlan的上本机的报文，会更新报文的输入接口，由从网卡驱动接收接口改为对应的桥端口或vlan子接口(vlan报文还会去除vlan头)，这是因为事实上上层协议栈关心报文的“逻辑”输入接口，而不是“物理”输入接口，这些报文的反向报文也是由上层协议栈发送到桥端口或vlan子接口，再继而转换为其原始的报文输入接口通往网卡驱动，简单的说就是网桥、vlan报文对于上层协议栈可见的是桥端口、vlan子接口。

综上所述，链路层的功能是提供协议栈与网卡驱动的接口、协议栈上层的接口(按以太网类型)、直接转发(网桥或L2隧道)，另外邻居子系统实现了链路层和网络层的映射(对于IPV4为arp)，另外需要注意，netif_receive_skb是在软中断处理函数调用的，也就是说整个协议栈报文处理是处于软中断中。

接口的概念：

接口可以理解为链路层的每一个收发单元，每一个接口可以对应实际的一个网卡，也可以是一个没有实际物理设备驱动对应的“虚”接口，比如网桥接口、vlan子接口，不论是“虚”接口还是“实”接口，在内核中都是以net_device结构体描述；

对于网络层，最重要的工作是选路，即确定路由，而确定路由就是确定报文是转发还是上送本机，如果是转发的话从哪个接口发送(skb->_skb_dst)，并且路由判决所需条件也包括报文的输入接口即报文是从哪个接口上到网络层的(skb->dev)，除路由之外，上层协议栈其他部分也经常关注报文的输入接口和路由转发接口；

所以接口是报文实际输入输出的逻辑路径，但不一定是物理路径，如某报文的路由结果是从eth0.5接口转发出去，那么这个eth0.5就是转发的逻辑路径，但它并没有实际的物理驱动，而是再通过vlan子接口处理最终仍由eth0实际转发报文，再如某报文由网桥br0上送到网络层，那么br0是该报文的逻辑路径，上层协议栈认为该报文就是从br0接收的，而实际该报文可能是由eth1实际接收的，经过网桥处理后输入接口变为br0的。

之所以会有“虚”接口，都是因为一些特殊的目的，linux需要实现网桥，需要实现vlan，而这些都是逻辑上的概念，并不真的存在某种物理设备叫网桥或者叫vlan，所以需要人为的制造出这些“虚”接口，以满足上层协议栈向下处理的统一性，而这些“虚”接口和“实接口的“虚实转换”，就是需要链路层实现的内容。

“实”接口一般由网卡驱动生成，因为网卡驱动管理实际的物理设备，所以一般诸如eth0、wlan1、usb2之类“实”接口由网卡驱动生成，网卡驱动负责这些“实”接口的ops实现；而“虚”接口一般由应用程序生成，如网桥、vlan子接口，内核源码负责这些类型的“虚”接口的ops。

可以把linux机器想象成一台能够实现交换机、路由器、主机的L2/3/4/5功能的结合体机器，“实”接口就是这个结合体机器的每个物理端口，“虚”接口表面上实现一些二层网络功能，如vlan子接口实现物理端口的vlan功能，网桥接口实现二层交换功能，而实际上这些“虚”接口同样被这个结合体机器的L3/4/5所识别。

二，网桥原理

网桥工作在链路层，所以它是二层的东西，对于以太网来说网桥和二层网络设备交换机的工作方式几乎是一样的，每个交换机包含一系列以太网接口，交换机通过其内部的硬件交换芯片实现对这些以太网接口出入报文的二层接收转发及过滤等二层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功能可以比二层交换机还要丰富。

三，linux的网桥实现

涉及文件：

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

• 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处理函数实现；
• l br.c：网桥模块初始化；

重要数据结构

网桥创建：

我们知道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))；

网桥接口添加：

创建网桥后，需要再加入接口，网桥的每一个接口在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)，一般情况下不必考虑桥端口的其他状态；

网桥报文接收处理

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

 

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

• 1、 需要进行桥接处理的报文，其输入接口必须属于某网桥；
• 2、 暂不考虑STP协议报文的处理，对于上图重点关注“报文转发流程”框之后的内容；
• 3、 桥接处理前会检查用户是否通过ebtables工具在链路层对报文进行过滤或其他处理，ebtables工具类似iptables工具，可以加不同的规则，区别在于它工作在链路层，这实现了类似二层交换机的qos功能；
• 4、 每次报文处理都首先进行动态MAC地址的学习或更新老化时间；
• 5、 对于某些操作，如对网桥进行抓包，这会使网桥自身接口被设置为混杂模式，这时必须把报文复制一份送至本地；
• 6、 组播/广播/未知单播报文会洪泛到每个桥端口，已知单播报文若目的端口为本机则送至本机，若非本机则从对应桥端口转发出去；可见网桥与二层交换机在单播和广播报文的转发方面是一样的，唯一区别在于组播报文的处理，在我们的网关设备上通过修改内核，是不允许组播报文在网桥上传播的；

网桥报文发送处理：

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

 

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

传入本机：

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

 

转发出去：

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

 

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

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

 

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