以太网交换机TRILL协议设计和工程实现

卓志强

摘 要：该论文讨论了TRILL协议在以太网交换机上的设计和实现方法。首先简要介绍了数据中心网络的发展和所涉及的技术，并提出了使用TRILL来构建数据中心二层网络。再介绍了TRILL中相关概念、工作原理和优势。提出了交换机上实现TRILL协议功能的模块模型、以及各个模块的实现。该论文的研究为实现数据中心交换机的TRILL功能提供了启发性的解决方案。

关键词：多链接透明互联 路由桥 数据中心

中图分类号：TN919 文献标识码：A 文章编号：1674-098X（2015）03（c）-0039-02

1 背景

信息化发展到今天，已经进入了云计算平台的时代，而服务器集群技术的高可用性和虚拟服务器动态迁移技术，在数据中心容灾及计算资源调配方面得以广泛应用，这两种技术要求实现大范围的二层的数据中心网络接入，而原先的标准——生成树协议（STP）因其一些固有缺陷将不再适合超大型数据中心的扩展。

STP在数据中心网络应用中的缺陷表现为以下几点：

（1）STP是通过阻断端口来工作的，所有的冗余链路不进行数据转发，该方式虽然解决了二层数据环路的问题，却带来了带宽资源的浪费，而数据中心因其巨大的数据通讯量，对带宽资源的浪费是比较难以接受的。

（2）STP整网只有一棵生成树，其特点是所有结点交换机都只看到从它自身到达根桥的枝干，如果一个桥设备要到达相邻枝干上的桥设备，哪怕它们之间有直连的链路，数据报文都要经过根桥中转后才能到达，这影响了整网的转发效率，同时造成了根桥的转发瓶颈，数据中心对数据转发的低延迟、瓶颈的丢包率需求会对此提出改进要求。

（3）以太网数据帧是没有TTL的，这会造成一旦数据在二层网络中出现环路，会造成整个网络立即瘫痪，而且还无法自愈，尤其是广播帧，这虽然不是STP协议的问题，但我们可归其为STP网络的问题。

2 课题的提出和意义

TRILL（Transparent Interconnec tion of Lots of Link，多链接透明互联）正是为了弥补当前STP协议在数据中心使用缺陷而产生的，其目标正是解决上述STP存在的问题。协议把2层配置和灵活性与3层融合和规模有效结合在一起。大二层不需要配置的情况下，就可实现整网无环路转发。为数据中心虚拟化（虚拟机+网络）奠定基础，更是为跨地域的数据中心之间的承载网网络（云网络）奠定基础。

3 TRILL协议分析与实现

3.1 TRILL标准分析

本课题研究我们针对的协议标准主要是RFC6325，RFC6326和RFC6327。RFC6325是TRILL协议草案，介绍了TRILL相关概念，同时介绍了TRILL协议转发面的实现。RFC6326介绍了TRILL控制面的实现。RFC6327介绍了ISIS for TRILL邻接状态机的过程。

3.2 TRILL工作原理

RFC 6325，RFC6327两个标准详细介绍了TRILL工作原理。RBridge通过运行的链路状态协议（通过ISIS扩展的）认知TRILL Campus的拓扑。并使用最短路径树算法生成从该RBridge到达TRILL Campus里的各个RB的路由转发表（称之为TRILL路由表）。RBridge接收到普通以太网数据帧时（这里专指802.1）查找Mac表，若该Mac源发自某TRILL Edge RBridge，就将数据帧转换成TRILL数据帧在TRILL Campus里转发，TRILL数据帧包含有源目RBridge信息，而RBridge则有到达各个RBridge的路由信息，这样RBridge可以对TRILL数据帧进行转发，当一台RBridge接收到一个TRILL数据帧时，该数据帧的目的RBridge为其自身，则解封装TRILL报头，获得最初进入TRILL Campus的以太网数据帧，再进行转发。

这也就是说TRILL作为二层转发技术，通过引入三层路由的链路状态发现协议将此前的Bridge升级为了具备路由能力的Routing-Bridge。

TRILL协议首先针对二层环路没有TTL的问题进行了改进，在TRILL报文头中引入了TTL字段（即Hop Count），这样TRILL报文在TRILL Campus中即使发生了环路问题也不至于造成严重的后果。

另外TRILL协议对多播及广播报文的转发设计了分发树的多播转发行为，与STP的生成树算法不同的是TRILL的分发树是从ISIS的网络拓扑中计算产生的，并为每一个VLAN生成一棵分发树，在发生VLAN变化或接口变化时，这种分发树的过程不需要额外的配置，完全是由RBridge自动完成的。当一台边缘RBridge收到一个某VLAN的广播帧或多播帧时，RBridge除了向自己的其它普通VLAN口分发该数据帧外，还要封装该数据帧为TRILL数据帧，目的RBridge為该VLAN分发树的根桥，通过根桥将该数据帧扩散的与该VLAN相关的其它所有RBridge设备上。

因此，TRILL有如下优势：

（1）带宽充分利用。

RBridge Campus与STP相比具有更好的网络带宽利用效果，这一特性对于数据中心场景而言具有很重要意义。TRILL构建网络的带宽资源得到充分的利用，不存在阻塞链路的情况。

（2）最优路径。

TRILL Campus的数据报文传输都是使用最短路径传输，这也明显优于STP。

选择最短路由进行报文传输是TRILL的技术特征，当同时存在多条最短路径的情况下RBridge应能支持ECMP功能，RBridge在转发中自动为其进行负载分担。

（3）易管理性。

TRILL的易管理性从组网上体现为将网络扁平化，这将大大降低网络管理的复杂性。

3.3 TRILL协议的概要设计

本章描述整个TRILL功能的模块划分，指明各模块所需具备的功能与职责；分析模块间的控制流与数据流。具体如下：

通过对TRILL的协议的数据面和控制面的需求分析，以太网交换机的TRILL协议实现主要由以下几个模块组成：

（1）ISIS模块。

负责实现TRILL控制面协议部分。要实现TRILL控制面协议，涉及：

①协议报文收发；

②邻居发现及其邻居表项下发；

③接口状态维护（DRB及指派forwarder），以及接口状态引起的端口配置变化。

④Nickname路由表的生成及其表项下发

⑤分发树生成，及其分发树转发表项下发。

⑥TRILL LSP通告处理

（2）Netlink Socket模块。

Netlink Socket模块是内核与应用程序交互的通讯模块，利用该Socket：

①将“二层接口表，RBridge信息，mac信息，VLAN信息”通告给ISIS模块；

②支持ISIS通过Netlink Socket写操作通告内核。

（3）TRILL RBridge模块。

该模块涉及的功能包括以下表项的维护建立：本地Nickname 表、RBridge邻接表、RBridge路由表（TRILL Nickname路由表）、分发树转发表。

（4）端口管理模块。

此模块对上提供二层接口列表的信息库，以及接口事件通告，接口状态维护等业务，对下挂接不同的接口驱动。

TRILL Frame驱动是挂接于二层接口之下的，端口管理模块要为TRILL生成逻辑接口，这里的逻辑接口还是逻辑链路接口，该链路接口所对应的逻辑物理接口为驱动层提供的逻辑物理口。其它与二层接口相关的功能模块都建立于逻辑接口之上。要想让TRILL针对所有这些二层接口之上的功能模块实现透明化必须关注以下关注点：

①TRILL报文接收时转化为TRILL逻辑接口向上递送。

②以太网报文CPU发送时查找MAC表，将查找到的出接口（邏辑接口）正确挂接到TRILL Frame设备上发送。

③要能区分识别出TRILL单播逻辑口及TRILL多播逻辑口，以便“TRILL Frame”模块能够正确发送TRILL报文。

（5）TRILL Frame模块。

此模块为TRILL Frame驱动，处理TRILL报文的封装和解封装，该驱动涉及与TRILL RBridge所维护的转发表项的查询交互：

①当接收到TRILL封装的报文时，负责为其解TRILL封装。

②当CPU向TRILL的逻辑接口发送报文时，负责为报文封装TRILL头。

（6）报文收发模块。

接收到TRILL报文时，调用“TRILL Frame”模块的接口解TRILL封装。

发送报文时，调用“TRILL Frame”模块提供的接口封装TRILL头。

4 结语

该文主要围绕如何在交换机上实现TRILL协议的基本功能和概要设计.

作者在项目实施过程中完成了系统主体数据结构设计，以及TRILL链路层实现编码、并进行了部分系统调试测试和交换机上各模块集成测试工作。成功的达到了在交换机上实现TRILL的基本功能，确保RBridge设备能够构建一个大二层网络，同时具备TRILL的ECMP特性。

由于作者水平有限，文中不免有疏漏甚至错误之处，敬请各位专家、学者和广大读者提出批评指正！

参考文献

[1] IETF RFC6325 （Routing Bridges （RBridges）： Base Protocol Specification）， 2011：1-40.

[2] IETF RFC6326 （Transparent Interconnection of Lots of Links （TRILL） Use of IS-IS）， 2011：1-30.

[3] IETF RFC6327 （Routing Bridges （RBridges）： Adjacency）， 2011：1-35.

[4] IETF RFC6439 （draft-ietf-TRILL-RBridge-af），2011：1-30.

[5] IETF RFC5556 （draft-ietf-TRILL-prob）， 2009：1-38.