详解TRILL技术及其组网模型

RBridge只需要知道到达下一跳RBridge的最优路径即可，无需知道如何到达目的主机。因此，只有Ingress/Egress RBridge需要使能传统的MAC地址学习(MAC表中区分从本地端口学到的MAC地址，以及从远端Egress RBridge上学到的MAC地址)，而TRILL网络上的核心RBridge无需维护与主机相关的MAC表。另外，RBridge之间可以采用传统以太交换机互联，并且在BRridge与互联交换机可运行STP协议，但RBridge会终结STP实例，不会将BPDU通过RBridge扩散。

图2. RBridge对多目的帧的转发

如图2所示，对于多目的以太帧(广播、组播、未知单播)的处理，要求RBridge通过TRILL IS-IS的计算结果生成出多棵具有不同树根的分发树。多目的帧进入TRILL网络，由Ingress RBridge选择一颗分发树用于该帧在TRILL网的转发，并将树根RBridge Nickname作为“TRILL头”中的Egress RBridge Nickname。此后的处理过程与IP组播报文在组播路由器间的转发类似，每个RBridge只根据树根RBridge标识的分发树选择TRILL的复制和转发策略。

需要说明一点，由于TRILL技术定义了新的帧格式，所以传统的以太网交换机不能通过升级软件支持该特性，只有采用新款ASIC/NP芯片的以太网交换机才能支持TRILL转发。

二、 TRILL的局限

虽然TRILL具备明显的特点，但它也存在一些问题待解决。到目前为止，TRILL还在不断的标准化过程中，依旧有大量的草案在讨论中。其协议本身问题主要包括：

不支持大于4K的VLAN扩展能力。对于虚拟化多租户的云计算数据中心，往往有大于4K的VLAN隔离需求，而TRILL的支持能力依旧限定在4K以内，难以满足需求;

OAM支持能力弱;

由于TRILL多用于数据中心，RB之间多是直连组网，不跨越传统Ethernet网络，对于这种组网，TRILL的外层以太头封装显得多余，可以精简优化。

只支持Level0，没有Multi Level的机制;

没有考虑如何承载FCoE业务。

三、 TRILL的应用

TRILL在国内的应用目前还处于起步阶段。部分运营商、金融、大企业以及互联网公司用户已经开始在关注或者开始考虑TRILL技术。

TRILL的组网需要考虑下列因素：

收敛比大小

L3网关的部署位置

L3网关的负载分担方式

设备本身MAC/ARP表项的大小

具体到组网应用，按照部署场景列举如下几种组网类型：

1. 组网模型1：现有组网扩建TRILL域

leaf+aggregation+spine三层组网环境，L3网关在aggregation层，集中式L3网关

图3. 现有组网扩建TRILL域

组网说明(如图3所示)：

在现有的POD基础上，横向扩展新的TRILL POD域，TRILL域的L3网关在aggregation层，向上和核心层通过路由协议对接;

为了解决leaf层的双活接入的问题，leaf节点支持N:1虚拟化，如H3C的IRF;

两个aggregation节点也做N:1虚拟化，以便免VRRP配置，实现L3转发的流量在网关的均匀分担;

由于现有商用ASIC难以支持在一个Pipeline中同时处理TRILL+L3，那么aggregation节点处如何实现TRILL+L3转发?

采用板卡代理的方式：将设备上TRILL和L3分开到两种不同的板卡上，然后在他们之间启用proxy代理，本质上是将原先一个芯片一个pipeline流程分解到两块芯片上分开执行，降低对芯片的要求。典型的如思科N7K上的M1/F1板卡组合;