云数据中心网络虚拟化——大二层技术巡礼之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对比如下

隧道类型

控制平面

多路径ECMP

组播树

头端复制

多拓扑

TRILL

MACinNickname

IS-IS

基于Hash

全网一棵MDT

不支持

不支持

SPB

MACinMAC

IS-IS

基于ECT

SPT per BEB

支持

支持

MTU探测

网关一体化

租户数量

兼容性

OAM

场景

TRILL

支持

计划支持

通过FGL扩展为16 million

可与以太网交换机混合组网

目前不支持

数据中心内部

SPB

配合其他机制

不支持

I-SID作为标签,支持16million

天然的兼容性

可以配套其他机制

数据中心,运营商骨干网

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

作者简介:
张晨,北京邮电大学未来网络理论与应用实验室研究生
主要研究方向:SDN、虚拟化、数据中心
个人博客:http://sdnv.xyz/
个人邮箱:zhangchen9211@126.com


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。
  • 本文链接http://www.sdnlab.com/15823.html
  • 本文标签技术/tech

分享到:
相关阅读
0条评论

登录后才可以评论

张晨 发表于16-02-13
0