云数据中心网络虚拟化——大二层技术巡礼之L2 Fabric技术传输隧道

NVo3是L2 over IP/MPLS，利用IP网络的智能传输作为大二层虚拟交换机的背板走线，其好处是利用现有的设备即可完成隧道的传输。不过同时这也带来了一定的问题——IP网络的传输路径、服务质量难以控制，而且往往需要IP网络支持组播。尽管MPLS能解决这一问题，但是其部署过于复杂，开通一个租户的实例动辄要上月的时间，已经难以跟上公有云业务的发展。从NVo3工作组形成Geneve的思路来看，是希望IP Router能够感知到隧道承载的内部L2业务的需求以便提供匹配的传输管道，不过要改造现网的设备可绝非一件容易的事情。这几年以TRILL和SPB为代表的Switch Fabric技术则另起炉灶，走了一条非IP传输的路线，同样满足了大二层所需要的传输智能和可扩展性。

1)TRILL TRILL（Transparent Interconnection of Lots of Links，RFC 6325），是一种把三层的链路状态路由技术应用于二层流量传输的协议。TRILL为二层网络添加了基于IS-IS路由协议的控制平面，这种基于路由的寻址方式使得二层网络的转发变得更加智能，同时也使得二层网络摆脱了STP的束缚，获得了高效性和可扩展性。下面来看TRILL的报文格式。

TRILL的封装在本质上是一种路由封装，它的寻址发生在网络层，因此不妨将TRILL比对着IP路由来看。TRILL设备被称作RB（Routing Bridge），可类比IP路由器。报头中，DA/SA为Egress/Ingress RB的MAC地址，在转发过程中逐跳重写。TRILL hdr可类比为IP header，其中Ingress/Egress Nickname唯一标识了Egress/Ingress RB的网络层地址，是TRILL寻址的依据，类比于源/目的IP地址，Hop字段则可类比于TTL用于环路避免。

TRILL控制平面的工作可概括为：首先在RB间建立邻居，绘制拓扑，然后生成RB Nickname路由表，同时允许通过ESADI协议维护虚拟机MAC地址和其所在RB的 Nickname间的映射关系。数据平面转发流程可概括为：收到虚拟机的原始帧后，Ingress RB为Original Frame封装TRILL报头，根据C-DA标记Egress Nickname，并根据Egress Nickname路由给下一跳的Transit RB，Transit RB继续逐跳路由到Egress RB，最后Egress RB剥掉TRILL报头，根据C-DA进行转发。TRILL域中，单播流量的路由依赖于RB Nickname路由表，组播流量的路由依赖于双向组播分发树MDT。下图给出了TRILL域中，终端A向终端C单播的完整通信流程，和IP的路由过程没什么区别，这里就不再做细致的说明了。

TRILL是独立于IP的网络层协议，或者说是一套庞大的协议集。除了上述的转发过程外，还规范了RB间点对点的PPP封装，Nickname的动态配置协议DNCP（类似于IP中的DHCP），Nickname的解析机制（类似于ARP），RB发现TRILL Hello，MAC地址分发协议ESADI，单播路由协议IS-IS，多路径负载均衡机制，组播分发树计算，路径MTU探测机制，等等。TRILL还考虑了RB间通过以太网交换机互联可能产生的种种问题，支持TRILL RB与以太网交换机的混合组网。

总之，作者很难用高度概括的语言把TRILL的技术细节都说清楚，下面列出一些作者在阅读TRILL RFC文档时注意到的技术点，可能比较琐碎，仅供读者参考。

• RB的MAC地址学习分为本地VM学习和远端VM学习。本地学习机制同传统二层自学习，维护（VLAN，MAC，Local Port）的转发表；远端VM学习维护（VLAN，MAC，Remote RB Nickname）的转发表，可以通过很多方式进行学习，必选的方式有如下两种：a.同传统二层自学习，解封装后学习内层源MAC地址和外层源Nickname的映射关系。b.通过ESADI（End-Station Address Distribution Information）协议进行学习。
• ESADI协议封装在标准的TRILL Data帧中，包含了RB Nickname和该RB本地的MAC地址信息。它使用All-ESADI-RBridges Multicast Address作为内层的MAC地址，在所有的参与ESADI学习的RB中进行组播，能够透传以太网设备。ESADI支持对VM迁移的感知。
• RB的Nickname与MAC地址的解析通过TRILL Hello实现。
• RB之间可以通过点对点进行互联，也可以通过以太网进行点对多点的互联。通过以太网互联的RB间需要选举出一个DRB，负责确定以太网中TRILL Hello，TRILL IS-IS，TRILL Data和普通以太网帧所使用的VLAN，并确定一个Appointed VLAN-X Forwarder。Appointed VLAN-X Forwarder负责以太网上的环路避免，监听STP BPDU、IGMP等以太网信令，生成、转发ESADI消息等等功能。
• TRILL Data帧在以太网上传输时，外层帧中的VLAN ID应该与内层原始帧的VLAN ID保持一致。TRILL的控制信令在以太网上分配的VLAN应该使用较高的PRI。
• 基于Hash，支持16条路径的ECMP。
• 整个TRILL域只计算一棵以RBi为根的分发树，其余的RBi间的通信都依赖于这棵树。可以通过IGMP、MLD或者MRD进行per VLAN MDT Optimization。
• 不支持头端复制的伪广播。
• 不支持IS-IS多拓扑，没办法针对VLAN为链路分配不同的metric。
• 有两种防环机制，一种是Hop Decrement，另一种是RPF用于避免分发树中的环路。
• 目前不支持网关一体化，不过通过VDC类技术可以做垂直整合。
• 规定了两种新的IS-IS消息用于路径MTU发现——MTU-probe和MTU-ack。
• TRILL只能用于Customer Environment，不能用于Provider Environment。
• 支持SNMPv3进行远程管理。

标准的TRILL使用VLAN作为租户的标签，在租户数量上收到了很大的限制。因此，TRILL工作组在RFC 7172中提出了对TRILL中VLAN标签的扩展技术FGL（Fine-Grained Labelling），其封装格式如下图所示，Inner Label High Part和Inner Label Low Part中的后12位，合起来提供了16million的租户数量。至此，TRILL在技术上体系算是齐活儿了，既提供了足量的Tag，又有着智能、可扩展的backplane，通过TRILL的连接，整个以太网变成了一台无阻塞的巨型交换机，为实现数据中心内部的大二层提供了完整的解决方案。

Cisco有一个私有技术，名为Fabric Path，除了实现TRILL的功能外还有很多自己的私货，如跨多拓扑FTAG、设备链路聚合vPC和基于会话的MAC地址学习等等，不过Fabric Path不支持与以太网交换机混合组网。TRILL的很多东西都是从Fabric Path那里copy来的，当然Cisco也乐于看到这种情况，毕竟技术上一脉相承，两者是站在同一条船上的。Cisco号称Fabric Path能够完美地兼容TRILL，不过看其它厂家的资料都说Fabric Path和TRILL还无法混合组网。

有人先成功，就有人要插一脚。瞅准了TRILL报头中增加了新字段，避免不了要设计新的芯片，对传统网络的兼容性不够好，SPB就趁机崛起了。

2)SPB

SPB（Shortest Path Bridging，802.1aq），常指SPBM，是前面提到的PBB（802.1ah）的小兄弟。两者的封装完全相同，都属于MACinMAC的隧道技术，两者主要区别在于PBB的转发是通过STP和自学习完成的，而SPB则为以太网引入了控制平面，通过IS-IS协议学习转发信息。SPB设计之处是为了解决运营商骨干PBB网络中STP收敛太慢、链路利用率低下的痼疾，恰好数据中心中内部也面临着同样的问题，市场不愿TRILL一家独大，便把SPB拿来与TRILL做了对头。

上图最右边给出了SPBM的帧格式，其中B-SA和B-DA为外层MAC地址，结合B-VLAN作为传输网络中的转发依据，而I-SID是24位的业务标识，作为租户的标识，同样提供了16million的租户数量。除了SPBM以外，SPB还有另外一种模式SPBV。这种模式与802.1ad类似，是一种QinQ的VLAN标签栈技术，不属于隧道技术的范畴，下面主要对SPBM模式进行介绍。

SPB控制平面的工作可概括为：在BEB（Backbone Edge Bridge）间建立邻居，绘制拓扑，然后根据最短路径算法生成B-MAC转发表。数据平面上，入口BEB根据原始帧内部的目的MAC地址标记B-DA，并根据B-DA地址转发给下一跳的BCB（Backbone Core Bridge），BCB继续逐跳转发到出口BEB，最后出口BEB剥掉外层的封装，再根据内部目的MAC地址进行转发。

同TRILL一样，SPB也是独立于IP的一套完整的转发机制。不过相比于TRILL，SPB由于用到的是MAC寻址，不用设计新的网络层协议，因此相对来说要简单一些。虽然如此，SPB的内容也是很多的，下面列出一些作者在阅读SPB RFC文档时注意到的技术点，IEEE的标准文案作者没有权限查看，如果哪里写的不对请大家多多指教。

• SPB的地址学习机制如下：BEB上的本地C-MAC转发表（C-VLAN，C-MAC，Port），远端C-MAC转发表（I-SID，C-MAC，B-MAC）都是通过自学习获得的，而BCB上的B-MAC转发表（B-VLAN，B-MAC，Port）则通过IS-IS学习。
• B-VLAN与I-SID不是一一映射的，多个租户实例可以映射到同一个B-VLAN中。
• 基于ECT（Equal Cost Tree），支持16条路径的ECMP。
• SPB的组播通过SPT实现，每个BEB都会以自己为根计算一棵最短路径树SPT，而不是像TRILL一样全网一棵分发树MDT。
• SPB中组播流量的B-DA格式如下所示，其中SPSrc标识了SPT的根即入口BEB，而I-SID的低24位则标识了租户特定的组播组。

• 支持头端复制的伪广播。
• 支持IS-IS多拓扑，允许针对不同的业务为链路分配不同的metric。
• 没有内生定义MTU发现机制。
• 兼容现网OAM机制，如802.1ag和Y.1731。

TRILL和SPB对比如下

从技术上来看，TRILL数据平面和控制平面兼修，更为完整也更有深度。而SPB则更为取巧，利用了现成的数据封装格式，只是添加了一些控制平面的逻辑。如果从市场反应来看，倒也不好说谁胜过了谁，毕竟SPB不需要对芯片做大型手术（可能要增加硬件对I-SID的支持），配套的协议也更成熟一些。Cisco肯定是TRILL这边挑大梁的，而SPB的阵营主力则是Avaya。Huawei和H3C则是两头堵，相对来说华为在TRILL上投入的更多一些，H3C可能在SPB上花的心思多一点。不过随着VxLAN的兴起，TRILL/SPB的势头也没有以前猛了，再算上DCI技术，三类隧道技术目前纠缠不清，市场究竟会做出什么样的选择呢？