拨云见日:FabricPath—从“交换”到“路由”

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




IT行业的发展一日千里,竞争的重点已经从参数、指标的追赶,发展到对标准、概念的主导,市场的领导厂商不再拘泥于设备的具体性能,而是通过掌握最有力的话语权来引导整个行业的发展,最终赢得客户的信任。

在这个争夺话语权的过程中,不计其数的技术名词被制造出来,成百上千的白皮书被PO到网上,如果我们连这些名词的真正含义都不清楚,别说赶英超美,可能被人家忽悠完了都浑然不知,因为至少在目前,信息技术的领军人物还在大洋彼岸,而且这个趋势还将持续很长一段时间。

这也是我写《拨云见日》的本意,就是要拨开表面的浮云,真正探究新技术的本质。在有限的篇幅里,我会以我的理解,尽力说明市场名词背后的技术实现,并摸清新技术产生的商业动机和相应的发展脉络。

今天我们来看看FabricPath是个啥。

关键词:FabricPath

厂商:Cisco

领域:数据中心网络

模糊程度:四星

一、为什么需要FabricPath

缘起

众所周知,Cisco正凭借Nexus产品平定整个数据中心网络市场,2010年,Cisco打出了深藏已久的最后一张王牌—FabricPath,至此,Nexus交换机的主要特性已全部面向公众发布,FabricPath为整个计划添上了最后一块基石,进一步稳固了Nexus作为下一代数据中心网络平台的地位。

大部分人(包括我)第一次阅读FabricPath华丽的白皮书后,只朦胧地知道这是一个“能在大型二层数据中心网络实现多路径的东东”,既然FabricPath解决的是数据中心的问题,我们首先需要弄清楚数据中心到底有什么问题。

今天的大部分数据中心网络是遵循标准的层次化理念建设的,分为接入层和汇聚/核心层,接入层和汇聚层之间为二层链路,三层网关设在汇聚或核心,所有的二层链路上都运行生成树协议(STP),当任意两点间有一条以上路径可达时,STP会block多余的路径,以保证两点间只有一条路径可达,从而防止环路的产生。这种模式在过去很长一段时间被大规模采用,因为其部署起来非常简单,接入层设备不需要复杂的配置,大部分的网络策略只要在汇聚层集中部署就能分发到全网。但随着数据中心的规模不断扩张,这种模型逐渐显得力不从心。

未来数据中心内部的横向流量将越来越大,新加入的设备同原有设备之间仍然要运行STP,如果两台服务器之间只有一条链路可行,其余的万兆交换机端口全被block,不但是投资的极大浪费,也无法支持业务的快速扩展;其次,当交叉链路数量增加时,二层网络的设计会变得非常复杂,哪条链路该保留哪条链路该阻断?三层网关设在何处?类似这样的问题会冒出一大堆,这就失去二层网络配置简单的优势;最后,传统的二层MAC地址没有层次化的概念,同一个二层网络内的接入交换机上存储本网段所有设备的MAC地址,这很容易导致边缘设备的MAC地址空间耗尽,特别是在虚拟化的数据中心内,虚拟机的MAC地址数量可能以千计。

如果二层互联不能解决问题,另一种思路是在汇聚交换机和接入交换机上设置IP网关,通过三层路由将所有交换机连接起来,类似的解决方案还包括将网关设置在核心设备上,通过核心设备集中互联。这个做法以前也许勉强可行,但在虚拟化环境中,二层网络是虚拟机迁移的基础。虚拟化的最大特点是可以将业务动态部署到数据中心的任何计算资源上,如果这些计算资源(也就是服务器)被过多的三层网关隔离开来,也就失去了虚拟化的优势。

同时,采用三层接入设备会产生大量的三层网关以及无数个让网管人员抓狂的地址段。动态路由协议的行为往往难以预测,在重要数据中心,为了保证网络行为的可控性,每台交换机的路由策略都要经过仔细琢磨,这个工作量过于庞大;而如果采用静态路由,一旦后期需要改动某个地址段的范围,可能需要改写一大段接入换机的路由表,更不用提相关访问控制策略的变动。

至此,我们走进了死胡同,虚拟化的应用要求基础网络在扩展时保持一个完整的二层环境,而随之而来的STP和地址空间问题又成为绕不开的坎,在接受二层环境的同时,我们基本上也就同一大堆时髦的字眼say byebye了,这些字眼包括但不仅限于“动态扩展”、“多路径”、“快速收敛”、“层次化寻址”等等,仰望IP路由,二层网络就好象一个生活在原始社会的苦行僧,忍受着种种的考验,传统网络在支持虚拟化数据中心扩张时已经越来越吃力。

为了改变这种尴尬的局面,在烧掉大把银子之后,Cisco的FabricPath终于闪亮登场了!

目标

简单说,FabricPath是Cisco Nexus交换机上的一项技术特性,其目标是在保证二层环境的前提下,修复前文所说的缺陷,这个技术需要做到以下几点:

  • 实现两点间多条路径同时转发流量EMCP(Equal Cost Multi Pathing);
  • 类似IP网络的平滑扩展;
  • 快速收敛;
  • 防止广播风暴;
  • 保持原有二层网络配置的简洁性

更准确地说,我们要摆脱传统二层“交换”的弊端,在二层环境中实现类似三层IP的“路由”行为。

二、FabricPath:从“交换”到“路由”

L2不给里的原因

我们知道FabricPath的目标是为传统二层环境设计一个增强型方案,以屏蔽原来的缺陷,实现对数据帧的“路由”转发。要明白FabricPath是怎么做到这点的,首先要看看layer 2这些不给力的毛病到底是怎么出来的?

传统二层以太网环境中的数据转发是非常简单的,一台二层交换机一辈子干的活可以用以下几句话概括:

1)收到数据帧–>2)查看目的地址–>3)查看MAC地址表–>4)将数据帧从对应端口送出去

偶尔,当这个流程进行到第三步时,交换机会发现目的地址不在自己的MAC地址表中,它会怎么做呢?这台茫然的交换机就会将这个数据帧从所有的端口广播出去!没错,是整个帧从所有端口发送出去,希望其他交换机能知道正确目的地。且不说,这个方式在今天看来是多没有效率,当设备之间存在环路时,这种帧会被无尽地转发下去,最终形成广播风暴。

为了解决这个问题,交换机厂商引入了STP。STP的机制也极其简单,就是通过阻断二层端口来防止环路,并阻止数据帧从其接收到的端口再转发出去。

广播帧在任意节点只会被转发一次,避免了被永远转发下去。但如前所述,运行STP的代价是非常昂贵的,接入设备只有一条上联链路没被block,而且,在复杂的网络连接中,控制STP的行为变得很困难,一旦出现震荡,其收敛效率也非常低下。

另一方面,二层交换机通过学习接收到的数据帧的源地址建立MAC地址表,所有接收到的数据帧源地址都会被放进MAC地址表中,导致一台交换机可能学习到整个网段内的所有二层地址,就算它大部分时间只跟其中的一小部分有联系。

由此可见,今天的二层网络过于简单,交换机只会学习网络地址,不会基于学到的地址规划出一套转发数据的最优方案,它的问题类似于只有一个数据平面,没有控制平面的概念,这就导致二层交换机不可能有效地进行“路由”,从而引入了STP等一系列问题。

FabricPath的实现:新的控制平面

既然二层网络的问题是控制平面的缺失,FabricPath的思路就清晰了,那就是重塑一个控制平面。

为了能够高效地支持数据中心扩展,这个新的控制平面需要具备几个基本功能,包括

  • 主动建立邻居关系,并基于链路状态维护一个路由数据库
  • 支持等价路由
  • 支持灵活的寻址方式
  • 保留原有二层网络配置简单的风格

为了构建这样一个控制平面,FabricPath主要做了以下两件事:

1)新增一个二层帧头

2)增加一套简化的IS-IS路由协议

这个新的帧头添加在原有数据帧之外,包含了丰富的信息,其中最重要的三个字段是源地址、目的地址和TTL。

源地址和目的地址来自FabricPath新定义的一个名为switch ID的全新地址空间,任何一个新加入FabricPath网络的设备都会被分配一个1~4094之间的整数,作为唯一的switch ID,用于标识一台交换机的身份,也是节点之间进行路由寻址的依据。

TTL(Time To Live)字段定义了一个数据帧的最长生存周期。当生成一个数据帧时,其TTL字段被写入一个整数,每当其经过一台交换设备TTL就减一,直到TTL为零时,这个帧将被丢弃。TTL的概念是TCP/IP的基础之一,在FabricPath中,TTL承担了同样的任务,保证数据帧不会在成环的链路中被无限次转发,从而使得二层环境不再需要运行STP协议,不再有链路被Block,这是实现两点之间多路径转发的基础。

相较帧结构的变化,FabricPath更重要的改进在于引入IS-IS这样一套完整的路由协议。IS-IS是一个广泛运行于运营商等大型网络的路由协议,同OSPF类似,IS-IS也是一个链路状态协议,会维护一个链路状态数据库,相比MAC寻址这样的距离矢量行为,运行链路状态协议的设备能够在内存中建立一张包含全网设备的拓扑,并且在这个拓扑的基础上挑选当前链路状态下的最短路径来转发数据。IS-IS的效率很高,且IS-IS区域能平滑地平移、分割、合并,但相较OSPF最大的不同在于,IS-IS可以封装在链路层报文中支持多种网络层协议,而OSPF只能封装在IP包中支持IP协议,这就使得IS-IS能够很容易被移植到FabricPath中,为二层数据帧的转发提供路由服务。

FabricPath中实际运行的是一个简化版本的IS-IS协议,不再依赖MAC地址进行寻址,依靠交换机的switch ID工作,在节点之间交换IS-IS信令构建路由表,IS-IS协议会事先计算出最优路径作为数据转发的依据。有了IS-IS的助阵,FabricPath能够轻松地实现两点之间的ECMP、网络拓扑的快速收敛、以及快速的错误诊断等高级路由功能。

新的地址空间加上IS-IS协议,FabricPath基本建立起一个控制平面雏形,数据平面和控制平面各司其职。

如果你是个较真的同学,你的第一个问题该出现了,为什么不延用原有的MAC地址,而要兴师动众地加入一套新地址呢?

问得好!

FabricPath中的IS-IS协议会建立一套逻辑树结构,这个结构说明了任意两点间的最优路径,是交换机转发数据的依据。路由协议在计算逻辑树的过程中往往会用到设备的标识号,由于MAC地址在设备出厂时就固定了,不同设备之间的地址没有任何规律,如果使用MAC地址作为唯一标识,生成的将是一个随机结构,这有可能导致最终的转发路径不是当前的最优路径。由于路由协议的算法是写死的,要避免这种情况只能人工调整各个节点的标识大小,这种情况同部署STP时调整交换机的优先级,以保证最优的转发路径是一个道理。然而,FabricPath设计的初衷就是保留二层配置简洁的优势,如果将STP的老毛病一并带过来,无疑大大削弱了对客户的吸引力,不利于现有网络向FabricPath的迁移。

既然是从头设计一套全新的机制,不如追求一把极致,将所有复杂的工作都隐藏到幕后,只呈现给用户最简洁的一面,这就是FabricPath费尽苦心设计一套地址空间的出发点。

FabricPath的工作模式


上图中,数据帧在进入FabricPath网络时,会被打上新帧头,在FabricPath网络内根据帧头里的switch ID进行转发,离开Fabric Path网络时,脱去帧头,进入传统的以太网交换环境。要加入FabricPath网络,只需在交换机对应端口上启用FabricPath模式即可,所有的地址分配和路由策略都自动生成,无需繁琐的配置。

上图是一个典型的FabricPath组网,汇聚设备同接入设备之间为FabricPath网络,FabricPath网络内没有运行STP,多条链路都能够转发数据,目前版本的FabricPath支持16条等价路由,也就是说在使用万兆链路的情况下,任意两点间的带宽可到2.56Tbps(16条等价链路结合,每条等价链路为16个万兆portchannel)。

接入设备作为网关连接了传统以太网络同FabricPath网络,FabricPath网关上可以进行“基于会话的MAC地址学习”,只有那些目的地址为本地设备的数据帧的源地址会被放入网关的MAC地址表,其他数据帧的源地址以及广播帧的源地址都不会被学习,这就保证了边缘网关设备的MAC地址表里只保存与本地有会话关系的MAC地址,这个举措能够大大缩小虚拟化数据中心内接入设备的MAC地址表体积。

基于IS-IS的特性,FabricPath网络设备的switch ID可以动态修改,而不影响流量转发,当数据中心规模不断扩张时,可以利用FabricPath平滑地扩展其汇聚层,并在接入设备间实现高达16条二层多路径(ECMP)。

第二个问题

OK,这一切都看上去很美,但你有没有觉得哪里不对劲?这就是我对FabricPath的第二个问题,以上说的所有这些东西,新增帧头啦、新的选路机制啦,和VPN不是差不多吗?在今天这个技术过剩的时代,难道找不出一个能解决这些问题的现有技术,非要重新折腾出一套新玩意吗?

现有VPN技术种类繁多,但大多数都使用IP包承载,协议开销较大,这与二层具备的快速转发特性是背道而驰的,仅此一项就将IPSec等三层VPN技术屏蔽在可选项之外。剩下的二层VPN中最常见的是类似MPLS+VPLS的实现方式,MPLS是一个2.5层技术,专门用于大量数据的快速转发,但问题是,MPLS的控制平面仍然需要IP报文进行路由,每个节点仍需要进行IP配置,而部署一个MPLS+VPLS网络你觉得容易吗?反正我看着都觉得头大,如果一种局域网技术需要网管人员先学习一遍MPLS,我觉得这种技术基本也没啥戏可演了。

标准化

FabricPath是Cisco近期在数据中心领域最重要的一个发布,同时也预示着基础网络向下一代模型转型的开始。数据中心内不断增长的横向流量推动了二层多路径技术的迅速发展,FabricPath是这股潮流的重要组成部分,但Cisco不是唯一的声音。

目前致力于实现二层多路径的标准化组织主要有IETF和IEEE,两家的标准分别为TRILL和802.1aq,都采用IS-IS作为路由协议,实现方式大同小异。目前,TRILL和802.1aq都已接近完成,预计2011年底就能够正式标准化。

Cisco在TRILL的制定过程中参与极深,虽然FabricPath是Cisco的私有解决方案,但可以看作一个“增强版的TRILL”,是TRILL的基本功能加上“基于会话的MAC地址学习”、“Vpc+”和“多重拓扑”等高级功能的合集。

Cisco已经发布了支持FabricPath的Nexus 7000板卡,并且承诺现有架构与TRILL标准兼容,当TRILL正式标准化之后,只需要升级现有设备的软件,就能够与标准的TRILL交换机互联互通。

三、结语

随着数据中心内虚拟化应用的不断扩张,底层的数据行为也在悄然发生改变,带动了基础架构的演进。未来的数据中心不仅需要大容量、高密度的网络设备,还要能够顺应这种数据行为的变化,并反过来提供经过优化的网络平台,这种从量到质的变化将深刻影响数据中心技术的发展。

FabricPath是Cisco在这个方向的重要布局之一,结合之前发布的FCoE、OTV、VN-LINK等技术,一个新一代数据中心网络平台已经隐约可见,Cisco只待市场大转型的到来,再次一举确立在网络行业的领导地位。

了解FabricPath有助于我们认识数据中心网络的演进方向,把握整个行业的脉搏,从而形成自己的思考,得出自己的结论。

五分钟Q&A

1)什么是FabricPath?

FabricPath是思科Nexus交换机上的一项特性,能够实现二层多路径数据转发。FabricPath能够在二层环境实现类似三层的路由功能,帮助虚拟化数据中心网络实现平滑扩展。

2)FabricPath有哪些好处?

FabricPath网络不再需要运行生成树协议(STP),没有链路被阻断,大大增加了网络传输带宽,很好地支持了服务器之间迅猛增加的横向流量。同时,FabricPath能够实现类似三层的路由功能,支持二层网络的平滑扩展。

3)FabricPath与现有二层交换冲突吗?

FabricPath的前提是不破坏现有的二层交换行为,FabricPath网络对已部署的接入设备来说是一个透明连接。

4)如何部署FabricPath?

在支持FabricPath的设备上将端口配置为FabricPath模式,系统会自动完成地址分配、路由建立等行为,无需手动干预。

5)什么是TRILL?

为了实现二层多路径功能,IETF在RFC5556中定义了一套方法,命名为Transparent Interconnection of Lots of Links,又名TRILL。

6)FabricPath是私有协议吗?

FabricPath是Cisco的市场词汇,用来表示思科的二层多路径技术,所以,FabricPath不是一项私有协议,但它是思科的私有技术实现。

7)FabricPath同TRILL的关系?

Cisco在TRILL标准制定过程中参与极深,并且积极推动TRILL的最终成型。FabricPath是TRILL正式标准化之前,Cisco推向市场的“Pre-Standard”技术,基本内容与TRILL相同, 增加了“基于会话的MAC地址学习”、“Vpc+”和“多重拓扑”等高级功能。FabricPath架构与TRILL完全兼容,Cisco承诺FabricPath平台将全面支持TRILL协议,TRILL正式标准化之后,通过软件升级,现有FabricPath设备能够与标准的TRILL交换机互联互通。

8)什么设备能够支持FabricPath?

2010年Cisco在Nexus 7000交换机上发布了一块支持FabricPath的32口万兆光纤板卡,以及相应的软件。未来,FabricPath技术会扩展到更多的Nexus 7000和Nexus 5000交换机上。

9)市场上还有那些类似FabricPath的解决方案?

目前没有完全相同的产品,Juniper的QFabric在二层扩展方面与FabricPath类似,但QFabric是一个私有架构,目前也没有开放的时间表。

(21个打分, 平均:4.81 / 5)

雁过留声

“拨云见日:FabricPath—从“交换”到“路由””有127个回复

  1. 陈怀临 于 2011-03-21 9:12 下午

    我有时想。在江湖上,到最后,其实不是一个人自己多厉害。有天大的本事也有knowledge hole。厉害的是:能结交到多少厉害的朋友。

    我非常grateful认识【见面和没见面的】这些江湖上的朋友。是你们造就了弯曲评论。

  2. sniper 于 2011-03-21 9:55 下午

    厉害,受教

  3. hanx 于 2011-03-21 9:56 下午

    尊敬的首席,请教您怎么看vyatta这一类公司的发展。

  4. longw 于 2011-03-21 11:23 下午

    受益匪浅!

  5. jwc 于 2011-03-21 11:58 下午

    期待Qfabric的细节公开。正如作者所说,TRILL和802.1aq的SPB是类似的,我想应该是个有优缺点吧,不知能否进一步说说各自的优缺点。目前看着像是FabricPath的推广文章,只说了优点,没有说缺点。

  6. kevin 于 2011-03-22 12:14 上午

    私有协议。店大欺客

  7. aOne 于 2011-03-22 12:22 上午

    看完后感觉CISCO提出的这个fabricpath确实很时尚,但是有一个问题想问问诸位高手。就是这个IS-IS的“路由”学习(放在2层的话应该是MAC地址)

    比如,PC1发包到PC2,中间路过3个交换机,那么PC1的报到达SW1时怎么知道我应该转发到SW3,此时你会说通过ISIS学习啊

    好,通过ISIS学习能知道下一跳SW2

    疑问就出来了,ISIS如果通告的是MAC地址,那通告信息报文是不是很大(因为MAC地址没有网段的概念)。

    其次,文中说,只有目的为to self的报文才学习MAC,不是to self的不会学习。那么如果不学习MAC地址那怎么通告ISIS?

  8. bigrong 于 2011-03-22 12:29 上午

    没仔细看,但是看了一点开头就知道是好文章!弯曲需要这样的好文章,不仅仅是在cpu啊、硬件啊、软件内核啊。
    陈首席也说过这个事情。可惜我做不了了。

  9. Weibo 于 2011-03-22 12:35 上午

    原创好文章,支持!

  10. kernelchina 于 2011-03-22 12:40 上午

    cisco的知识传递做得不错,至少能让人看懂,至于J,基本上是看不懂,还是看的人少。很不错的文章,学习中。

  11. slayer114 于 2011-03-22 12:56 上午

    switch ID只有4094,是否意味着只支持到4094台交换机?现在虚拟化技术发展速度很快,许多网络设备本身就支持虚拟化,可能物理环境是几百台交换机,只要去vswitch一下就能轻易超过这个4094的限制。怎么解决?另外,新加入的帧头似乎没有安全上的考虑。简化的IS-IS也还是要协商的,既然协商就要携带足够的网络信息,是否模拟这种行为就可以轻易得到LSDB?甚至抓包改字段后回放就能攻击控制平面,从而使数据平面瘫痪,甚至可以引流。
    新技术不甚理解,随便谈谈观后感。

  12. 理客 于 2011-03-22 1:05 上午

    ISIS本来就是无IP的L2路由协议。
    这里其实很多不错的选项可以改造来用,包括MPLS,PBT等,思科另辟蹊径,可能还有一些非技术的ZZ考量

  13. 请教 于 2011-03-22 1:26 上午

    1,任意两点间带宽为160T怎么得来的?
    2,fabricpath下DC网络是一层结构还是两层结构?还有汇聚交换机和接入交换机的区分吗?J的Qfabirc宣称是一层结构。
    3,“只有那些目的地址为本地设备的数据帧的源地址会被放入网关的MAC地址表”这句话不太理解,是否指fp接入设备的MAC表维护?
    4,以太网帧进入FP网络时,根据目的MAC地址打swith ID吗?这个源MAC是否会被接入的FP设备学习?如果MAC表不命中,如何处理?
    4,Qfabric的转发机制是否了解,会类似trill吗?

  14. ABC 于 2011-03-22 2:01 上午

    对160T的计算是否有误?16条路径每条万兆,不是160G?
    ISIS通告的地址都是CLNS地址,和IP不一样,感觉通告的内容都是switch id.这样各自学习的都是switchid,至于MAC地址反而是不重要的了。
    从发布这个东西来看,还是为了解决横向流量的问题,网络结构并没有多大的改变。应该说实际上在接入层部署的时候使用支持该特性的机器,还是能够保证二层/三层网络结构。

  15. Lucifer 于 2011-03-22 2:49 上午

    不错的文章,看完就能理解了

  16. wenfish 于 2011-03-22 3:32 上午

    关于TRILL与1AQ的比较,可以参考这个链接中的文档。此文档由TRILL工作组co-chair编写

    http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTY0MyZuYW5vZzUw&nm=nanog50

  17. 某某 于 2011-03-22 3:56 上午

    作者了解802.1aq的情况吗?比如主推厂商,进展情况等等…
    正在规划数据中心,想多了解点。

  18. Soulhacker 于 2011-03-22 4:24 上午

    写了这么多,该看不懂的还是看不懂,很多人还是云里雾里的。我来总结成一句话吧:
    抛开底层实现,FabricPath就是个超大个的STP(生成树协议),在FabricPath和和STP之间还有个vPC(virtual port channel)就是个大型的STP。把这个要点抓住了,具体怎么实现的由厂商来担心就行了。

  19. 华为ptn 于 2011-03-22 6:40 上午

    这个和现在的什么ptn的概念是不是很相像?华为的ptn就是isis内部协议,然后通过vpn传递,符合mef的标准。觉得好像啊。不过ptn之间的节点好像是基于ip的。

  20. ZC 于 2011-03-22 6:53 上午

    Fabric Path不是STP,因为他可以实现全网数据抓发,没有树形概念,没有block概念。

    他的问题我感觉可能就是每台交换机都要维护一张全网的mac表,表内维护包括mac和对应的switch
    id信息。如果性能低的交换机可能撑不住。

    但是,也真由于Fabric path没有二层环路,所以网络拓扑可以任意复杂/冗余,单个交换机失败也不会影响其他设备运转。

    想当年,extreme networks曾经提过一个EAPS二层环概念,但是因为无法摆脱二层环路这个缺陷,导致无法建立复杂拓扑,复杂环的构建一直不清晰。简单环的话,环中每一个节点都有成为瓶颈的可能。

  21. ZC 于 2011-03-22 6:56 上午

    错别字一堆啊。。。

    可以实现全网/全路径转发

  22. 楼上楼下 于 2011-03-22 7:01 上午

    是不是为云计算准备的?

  23. Xin Qian 于 2011-03-22 7:38 上午

    H3C的IRF跟这个有联系吗?

    这路子确实是对的,数据中心的产品关心的不是redundancy/高可靠性,是快速转发和简单配置。

  24. libing 于 2011-03-22 7:55 上午

    To ABC

    谢谢指正,确实是笔误,应该是2.56Tbps,图中的160Tbps实际上是目前单个FabricPath网络内可以有8192个万兆端口,如果看作一个fabric,则双向交换能力正好是160Tbsp,具体细节见:
    http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_paper_c11-605488.html

    To aOne

    在FabricPath边缘网关设备上存在两个地址表,第一个指明了对端MAC地址和对应的最终FabricPath出口设备,另一个表指明了要达到这个出口FabricPath网关设备,有哪几条路径。“基于会话的MAC的地址学习”目的在于缩小第一个表的体积,也就是说和本地通信没有关系的对端信息不会存储。
    你可以理解为MPLS网络内PE设备上会存储好几个不同的本地路由表,缩小这个路由表是有意义的。

    To slayer114

    switch ID只会分配给交换设备,服务器不会参与FabricPath网络,这个数量能满足大多数需求。
    攻击行为是任何一个路由协议都会面临的问题,可以通过加密和认证来避免。

    To 请教
    1,任意两点间带宽为160T怎么得来的?
    已更正,谢谢

    2,fabricpath下DC网络是一层结构还是两层结构?还有汇聚交换机和接入交换机的区分吗?J的Qfabirc宣称是一层结构。
    目前是两层,汇聚和接入,如图所示

    3,“只有那些目的地址为本地设备的数据帧的源地址会被放入网关的MAC地址表”这句话不太理解,是否指fp接入设备的MAC表维护?
    是的,目的就在于优化FabricPath接入网关的MAC表体积

    4,以太网帧进入FP网络时,根据目的MAC地址打swith ID吗?这个源MAC是否会被接入的FP设备学习?如果MAC表不命中,如何处理?
    会打上传播路径上最后一个FabricPath设备的switch ID;FabricPath会学习这个源MAC;如果目的地址在MAC地址表中不存在,会进行一个标准的广播学习过程,只不过这个过程需要在FabricPath网络里走一遭,其行为同其它地址学习过程一样。

    4,Qfabric的转发机制是否了解,会类似trill吗?
    等高人揭秘

    To Soulhacker

    FabricPath同STP有本质区别

    To 华为ptn
    FabricPath的特点在于抛掉了IP

  25. libing 于 2011-03-22 7:57 上午

    To Xin Qian

    IRF和思科的VSS,VPC类似,对于下联设备来说,只能运行在两条上联链路上,超过两条就会有问题。

  26. kernelchina 于 2011-03-22 8:08 上午

    那是不是说一个数据中心,只能有一个fabric-path?

  27. wenfish 于 2011-03-22 8:24 上午

    libing看来对这个技术理解深刻,juniper的qfabric刚发布,网上信息找过一下,很少,能否提供一些资料?

  28. jiawenyu103 于 2011-03-22 8:38 上午

    数据中心网络,目前感觉是以虚拟化(H3C IRF和思科的VSS)+端口聚合技术组网比较流行啊!
    这样可以将原本复杂的核心、汇聚、接入的三堆设备,虚拟成“大的三台设备”!
    这样从维护成本、网络复杂度、网络冗余性方面都得到了很好的平衡。
    这样还有必要使用FabricPath 吗???

  29. donge 于 2011-03-22 9:12 上午

    802.1aq是北电同学主导,后倒闭802.1aq团队被我司收购,主导802.1aq,在转发上用MACinMAC,不需要修改硬件和芯片。曾经参与过讨论,目前不知道进展如何。
    TRILL是Cisco主导的,标准和产品化方面走得都很快,扩展了转发,加入了类似三层的TTL。但象文章中说的,变大了,我们也得follow。
    我挺看好IS-IS在L2的应用,尤其是即插即用,MPLS/IP实在复杂。

  30. zhoul 于 2011-03-22 9:20 上午

    我的理解
    IRF/VSS/vPC只能两台设备虚拟,多台不行,FabricPath与VSS不冲突,先做VSS,再做FabricPath应该也可以。
    个人认为FabricPath是跨区域多数据中心二层融合解决方案,方便以后虚拟机的漂移。
    目前垮区域多数据中心可以通过裸光纤、DWDM、或者租用MPLS L2 VPN实现,不知道FabricPath能否穿透MPLS L2 VPN。

  31. jiaruifu 于 2011-03-22 10:13 上午

    初步感觉FabricPath这种方式使用意义不大。

  32. jiaruifu 于 2011-03-22 10:17 上午

    I say no.

  33. HJ 于 2011-03-22 11:24 上午

    如果这种新技术期望实现和目前MPLS一样的功能的话,那么到时候其复杂度和成本不会比MPLS少多少的。
    个人感觉:意思不大,不如直接用VPLS(PBB)这个已经非常成熟的技术。

  34. igp2bgp 于 2011-03-22 2:20 下午

    小道消息brocade的vcs是ospf改的。
    这个TRILL loopfree是关键。

    pbb再好也是metro领域的,DC还没有用这个的吧?

  35. ilovebgp4 于 2011-03-22 4:26 下午

    这个东东看起来本质上跟MPLS没啥区别啊,都是基于标签的转发协议。只不过FabricPath/THRILL的标签是加在以太网外面而且信令换成了ISIS而已。

    话说回来ISIS本来就具备承载IP以外协议的扩展能力,因其最早是由DEC为ISO协议开发的,后来才扩展到能承载IP路由。JNPR的交换机集群(我指的是低端交换机的VC而不是现在正忽悠的Qfabric)也是这个思路。

    我提个疑问,这个修改版的”ISIS”势必需要维护全网MAC地址的LSP(Link-state PDU) Database吧,由于MAC地址是随机离散的不能汇总,加上FabricPath/THRILL要求的即插即用导致不能人工干预此ISIS配置,也就是不能对ISIS分Level,那么这个Database的扩展性就令人担忧了。尤其在交换机的控制平面性能较弱的时候。由于ISIS同一Level database是同步的,导致最弱的设备会成为整网的短板,不知道FabricPath是如何解决这个问题的?

  36. ilovebgp4 于 2011-03-22 4:32 下午

    感觉这个方案跟传统MPLS标签交换比起来并没有性能或价格上的优势,但是可能可以解决MPLS不能即插即用的问题,毕竟MPLS的配置还是比较麻烦的。

    而且MPLS不起VPN的话不能承载二层以太网业务,只能承载IP业务。

  37. 理客 于 2011-03-22 5:07 下午

    MPLS早期有很多FEC,后来没人用,就剩下IP了

  38. ilovebgp4 于 2011-03-22 5:38 下午

    理客:
    那我的话说的外行了,呵呵。

    PS:大伙都起得很早嘛

  39. jiawenyu103 于 2011-03-22 7:27 下午

    IRF/VSS/vPC只能两台设备虚拟,多台不行,FabricPath与VSS不冲突,先做VSS,再做FabricPath应该也可以。

    IRF/VSS/貌似可以多台堆叠聚合吧?

  40. 晃晃悠悠 于 2011-03-22 10:52 下午

    思科目前要的就是标准。
    后来者,对不起,跟着我混吧(或者合作)。

  41. Sting 于 2011-03-22 11:12 下午

    我很关心另外一个问题:标准的交换网片厂商是否有规划支持fabricPath

  42. Sting 于 2011-03-22 11:38 下午

    引用一篇文章。。。算作一半的自问自答吧

    思科Jawbreaker是对QFabric压力的反应
    发布时间 : 2011年03月19日
    观察人士仍在推测前一周发生的新闻。该新闻称思科正在开发新的基于博通(Broadcom)芯片而不是思科自己开发的ASIC芯片的Nexus交换机,也许就是光纤交换机。思科不愿讨论尚未发布的产品,所以也没有提供相关解释。
    一些分析师认为,Nexus/FabricPath是不完善的,没有把数据中心放在一个完全扁平的一层结构中。这可能就是思科需要开发新的产品线的原因。知情人士称,该产品线的代号为“Jawbreaker”。
    使用商品化芯片开发这种产品可减少开发客户化ASIC芯片的时间和成本,加快产品上市的时间。这是非常重要的,因为瞻博网络已经从自己的Stratus结构项目中推出了QFabric产品线。
    Yankee Group分析师Zeus Kerravala称,“FabricPath虽然减少了复杂性,但也只是从三层减少到二层而已。而瞻博网络的Stratus已经减少到了一层。”
    为扁平化网络铺平道路
    Jawbreaker还是思科试图现在这一市场上占位的一种做法。思科并不指望会在2012年年底前出货。而瞻博网络的QFabric将在今年晚些时候出货。
    思科期待很快会发布Nexus 3000交换机。这是专门为市场交易设计的低延迟高密度1U单元的万兆以太网交换机。知情人士称,Nexus 3000交换机采用博通的Trident芯片组。而Jawbreaker将采用博通即将推出的Trident+芯片。
    知情人士称,Nexus 3000不是Jawbreaker结构的一部分。但是,思科在金融交易部门的业务一直在流失给Arista和瞻博网络。因此,Nexus 3000的意图在于进行反击。
    Kerravala称,但是把产品建在商品化芯片之上严重偏离了思科的一贯做法。这个信号表明,思科正在感受到竞争压力。只有ASIC芯片能够为思科提供竞争优势,因为ASIC芯片是思科专有的技术。

  43. tom 于 2011-03-23 12:07 上午

    最终的fabricpath还是两层的,而j的已经是一层了,c已经慢了一拍了

  44. 请教 于 2011-03-23 1:35 上午

    感觉cisco有些偷换概念,按照FP access switch的规格,支持512*10G port,这无论如何也不是TOR位置的交换机能达到的,换句话说,如果FP的access switch无法放置到TOR位置,那么服务器和access switch之间如何连接?是否需要保护?
    感觉C的FP就是为胖树增加了动态拓朴学习能力,从网络结构上看没有J的QF优美,当然不知道J如何控制地址学习和动态寻路,但是应该不难做到。J的QF更接近scale up,当然FP的ECMP如果做不到在线可升级(感觉比较难做),也很难被称为scale out。

  45. nexus 于 2011-03-23 4:38 上午

    TOR switch 可以像以前一样通过port channel接入FP switch, FP switch上称为vPC+。

  46. nexus 于 2011-03-23 4:48 上午

    Juniper Qfabric 有两个宣传点;1-one hop, 2- one management point。 应该类似 T4000+PTS9000的结构,考虑Juniper的人喜欢BGP,估计使用一个类似 Routing Node的东东集中处理 Neighbor和MAC/IP更新。QFabric大麻球中间的交换核心在开始时估计没有冗余 …

  47. kernelchina 于 2011-03-23 6:35 上午

    one hop怎么理解?是packet只经过一次转发吗?但是J的方案里面,好像是两个设备。
    还有这个二层的路由,如果是基于目的MAC去查,由于没有掩码,会不会路由表的容量有限制,或者支持接入的主机数量是有限制的。
    现在典型的数据中心,接入点的数量是多少?千个,还是万个?

  48. bneliao 于 2011-03-23 6:46 上午

    跟mpls很相似,估计也是旧瓶换新酒。不过,可扩展通信寻址方式也折腾不出什么新东西了。就两个字段,一个具有全局意义的地址字段,一个局部意义的地址字段。
    不知有哪位高人能不能写篇文章详述MPLS的FEC?

  49. Fang 于 2011-03-23 7:04 上午

    很好的文章,支持!

  50. libing 于 2011-03-23 7:05 上午

    To ilovebgp4

    谢谢你提到了一个非常重要的问题,就是整个系统的扩展性,这也是FabricPath进行“基于会话的MAC地址学习”的初衷,用以在边缘设备上控制MAC地址表的大小。

  51. libing 于 2011-03-23 7:08 上午

    你可以说FabricPath是一个重新包装过的MPLS,但我仍然觉得它是一个非常漂亮的方案,其出彩的地方就在于简化了部署成本,几条命令搞定(至少其出发点是如此)。

    对于大多数用户来说,一个简单易懂的方案比什么都强。

  52. libing 于 2011-03-23 7:15 上午

    to kernelchina

    你的问题非常好,控制MAC地址表是非常重要的。因此,在FaricPath的边缘网关上不会存储所有MAC地址,只会保留与自己有会话关系的对端MAC,也就是”基于会话的MAC地址学习”,这也是FabricPath相对TRILL增强的地方之一。

    我很想找一篇文章能清楚地解释这个问题,但目前为止还是只能请你读FabricPath的config guide,sorry:http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/fabricpath/configuration/guide/fp_switching.html#wp1675983

  53. viaduct 于 2011-03-23 1:28 下午

    TRILL和802.1aq已经有主流芯片支持,和前面多位同学一样,很多方面本质上和L2 MPLS/VPLS没有什么差别,但套用一句流行语,用户体验做得更好。

  54. CCC 于 2011-03-23 2:03 下午

    one hop怎么理解?
    —-数据包在通过整个QFABRIC时仅入口交换机查一次表

  55. CCC 于 2011-03-23 2:05 下午

    思科的FabricPath在扩展无阻塞数据中心网络时存在一些缺陷,因此未能充分地容纳数据中心的3层流量。
    观察人士仍在推测前一周发生的新闻。该新闻称思科正在开发新的基于博通(Broadcom)芯片而不是思科自己开发的ASIC芯片的Nexus交换机,也许就是光纤交换机。思科不愿讨论尚未发布的产品,所以也没有提供相关解释。
    一些分析师认为,Nexus/FabricPath是不完善的,没有把数据中心放在一个完全扁平的一层结构中。这可能就是思科需要开发新的产品线的原因。知情人士称,该产品线的代号为“Jawbreaker”。
    使用商品化芯片开发这种产品可减少开发客户化ASIC芯片的时间和成本,加快产品上市的时间。这是非常重要的,因为瞻博网络已经从自己的Stratus结构项目中推出了QFabric产品线。
    Yankee Group分析师Zeus Kerravala称,“FabricPath虽然减少了复杂性,但也只是从三层减少到二层而已。而瞻博网络的Stratus已经减少到了一层。”
    为扁平化网络铺平道路
    Jawbreaker还是思科试图现在这一市场上占位的一种做法。思科并不指望会在2012年年底前出货。而瞻博网络的QFabric将在今年晚些时候出货。
    思科期待很快会发布Nexus 3000交换机。这是专门为市场交易设计的低延迟高密度1U单元的万兆以太网交换机。知情人士称,Nexus 3000交换机采用博通的Trident芯片组。而Jawbreaker将采用博通即将推出的Trident+芯片。
    知情人士称,Nexus 3000不是Jawbreaker结构的一部分。但是,思科在金融交易部门的业务一直在流失给Arista和瞻博网络。因此,Nexus 3000的意图在于进行反击。
    Kerravala称,但是把产品建在商品化芯片之上严重偏离了思科的一贯做法。这个信号表明,思科正在感受到竞争压力。只有ASIC芯片能够为思科提供竞争优势,因为ASIC芯片是思科专有的技术。
    Kerravala认为,后续版本的Jawbreaker和Nexus 3000交换机将配置ASIC芯片,而不是现成的处理器。其他分析师认为,思科使用商品化芯片的决定反应了思科对这种设备性能的信心,当然还有成本上的考虑。
    Enterprise Strategy Group(企业战略集团)主要分析师Jon Oltsik称,“由于Arista、Force10和瞻博网络等每一个交换机厂商都在使用商品化的芯片,所以思科现在觉得采用此类芯片应该也不错。我认为,我们在这里看到的是一种财务上的决策。既然又要维持利润水平,又要降低成本,唯一的办法就是使用商品化芯片。我认为这是一个聪明的选择。”
    至于Jawbreaker,Oltsik认为,Nexus/FabricPath是为普及以太网光纤通道(FCoE)优化的,而不是为了数据中心结构的扁平化而设计的。思科是把以太网光纤通道用于虚拟化存储的积极布道者,把它当作了另一种在以太网上的通信类型。
    Oltsik称,“Nexus/FabricPath产品原是为以太网光纤通道设计的,而不是为数据中心的桥接/TRILL(多链接半透明互联)设计的。因此,我的预感是Jawbreaker是下一代版本的FabricPath。换句话说,我不认为思科会同时提供这两种功能。按照我的观点,Jawbreaker的目标是一个带存储功能的扁平网络。从这个意义上说,它与QFabric非常相似。”
    不惜模仿QFabric
    的确,瞻博网络也是这样看这个问题的。瞻博网络结构与交换事业部负责产品营销的副总裁Andy Ingram在“Network World”网站对Oltsik的博客发表评论称,“思科的FabricPath在扩展无阻塞数据中心网络时存在一些缺陷,因此未能充分地容纳数据中心的3层流量。”
    Ingram称,QFabric“改变了以太网交换机的扩展模式”,这种扩展是向分布式和联邦制单元扩展,而不是扩展成多台以太网交换机。通过“重新考虑数据平面、控制平面和管理平面,QFabric可扩展到6000多个端口和每秒44TB的横截面带宽,同时又保持单台交换机的运行模式。”
    Ingram在博客中称,看起来甚至思科也同意瞻博网络的方法。思科的Jawbreaker项目正在回避之前的FabricPath,而试图模仿QFabric交换机。
    思科的另一位竞争对手称,甚至当前的Nexus 5000和7000交换机在结构上也是不一致的。Jawbreaker则试图纠正这种状况,同时,Nexus 3000必须尽快投放市场,才能在金融交易市场与Arista和瞻博网络争夺市场份额。
    该竞争对手称,Nexus 7000和Nexus 5000是为不同的目的设计的。Nexus 7000是大型高速模块设备,功能丰富,价格不太贵。Nexus 5000是把以太网光纤通道引入市场,支持统一计算系统。从命令行接口(CLI)的角度看和从转发平面的角度看,把所有这些设备连接在一起像一台交换机那样工作几乎是不可能的。因此,他们制作了一个新的架构以便加快投放市场与瞻博网络竞争,因为这是他们以节省成本的方式提供这种能力的唯一途径。

  56. 陈怀临 于 2011-03-23 5:56 下午

    如果是我写,我会把题目改成:从路由到交换。正好反过来。但感觉意义就很不一样了。。。

  57. nexus 于 2011-03-23 6:29 下午

    FabricPath 是特定数据中心的特定解决方案,TRILL的名称已经很好的定义了他的应用场景。FabricPath不是交换机设计理念,或者说不是交换机集群设计方案。个人认为 QFabric作为封闭的交换机集群的设计思路,可能有个别客户采用,大多数用户还是会采用开放的,标准的技术和设备。 随着单个交换机设备的能力越来越高,(80G/slot–>480G/slot), 集群方案会回到以前的双节点方案,循环上升吧。。。

  58. 请教 于 2011-03-23 7:14 下午

    to nexus:
    1,TOR通过vpc+接入FP switch确实可以解决可靠性问题,但是这时我们看FP网络结构:TOR-FP access-FP aggregation-FP access-TOR,这和现有的DC树形网络结构好象没有差别,c强调的由3层简化为2层指甚么?难道是把FP整个做为一层?当然j的QF所谓一层说,也没有把QF/interconnet作为一层。

    to kernelchina:
    1,one hop可能就是指数据帧只经过一次转发,即TOR->TOR,J的QF更类似集群概念,中间的QF/interconnect他是不算作一条的。而C的方案明显要多一跳,即TOR->FP->TOR。跳数影响的是时延,对DC来讲,尤其对HPC来讲,时延是很关键的规格;
    2,MAC表容量问题,跟DC内部业务在服务器上的分布有关,实际上一台服务器不可能跟所有DC内部其他服务器都有通讯,因此可以想象只要遵循C的所谓“根据会话学习MAC”,MAC地址表容量是有限的,J的QFX3500的96K容量应该是经过评估的。

  59. nexus 于 2011-03-23 10:36 下午

    FabricPath (FP SW–>FP Spine SW –>FP SW) 可以看成3-stage 交换网的 S1–>S2–>S3, 结构和目前DC的树没区别,可是别忘了 不采用 FabricPath/TRILL, DC的树最多是个2 叉树 …

    一个交换机可以看成几层 ?入接口板 –>交换网板 –>出口板 , 共三层 ?层次的谈论我个人认为无意义 …

    “Low latency switch” 纯粹是炒作,入口为千兆,出口为万兆, 你来Cut-Through Forwarding 一下,交换机会断气的 … HFT/HPC用的交换设备只是交换设备中很小的一部分,用到的技术一定不适合大范围的交换机用户。个人认为谁的设备宣传交换延时多么短,谁家的设备的QoS能力和三层转发表的容量肯定不行.

    MAC地址的学习,最快的就是传统的Floodiing学习方式,其它的办法解决的是扩展性,这就和应用有关了;在当前VM盛行的时候,别说96K了, 128K都不一定够用。(另外,L2 CAM是够用了,L3 ARP表够用吗 ), 真希望以后的数据中心服务器都采用/32的地址 … 世界就清净了 。

  60. libing 于 2011-03-23 11:18 下午

    “如果是我写,我会把题目改成:从路由到交换。正好反过来。但感觉意义就很不一样了。。。”
    这才是真正的市场导向mind set!

    我也觉得强调one hop意义不大,QFabric内部是个私有架构,数据的封装怎么玩都可以,但这种架构遇到扩展和互联就抓头发了

    前面说到的数据中心之间扩展,cisco有另一套东西–OTV(太能折腾了)

  61. jiaruifu 于 2011-03-24 12:07 上午

    SPB、TRILL均增加了二层网络“东西方向”的交换速率,但是二层网络“南北方向”的转发速率因插入新的交换包头而会降低。目前对于一个正常的DC网络来讲,南北方向流量是最重要的业务。

  62. libing 于 2011-03-24 12:39 上午

    To Jiaruifu

    传统二层网络中如果运行STP,只有一条上联链路可以传输数据,FabricPath带来的多路径能力相较帧头增加的时延,还是极大地优化了南北方向速率。

    当然,在目前很多数据中心内,VPC也有不错的效果

  63. jiaruifu 于 2011-03-24 12:46 上午

    To libing
    您说的我也有考虑,但是对于主机系统来说,一个网卡只有一个MAC进行交换,在南北方向再多的多路径交换都是白搭。感觉南北方向这块还有很大的改进和优化空间。
    VPC有无材料链接我也研究研究。

  64. jiaruifu 于 2011-03-24 1:10 上午

    再多的多路径怎不能比两点一线的直连还效率高吧,况且南北方向的多路径交换感觉还不存在。

    这样的交换不但要增加帧头而且还要释放帧头。这块对时延的影响应该可以做出一篇很好的研究论文。

  65. zeroflag 于 2011-03-24 2:09 上午

    第一次认识到“二层路由”(我是这么称呼Trill和类似技术的)的重要,是在研究数据中心FAT TREE拓扑结构的时候,当时发现在FAT TREE结构下,如无“二层路由”,则整个拓扑基本上是不能在二层环境下正常工作的。不过,随着技术的进步,我们是否有必要采用这种复杂的拓扑值得商榷。这是其一。

    其二,Trill也好,FabricPath也罢,只要做二层路由,就需要对每个MAC地址进行路由,MAC地址不分层,这个巨大的二层路由表想想就觉得恐怖(最少也要十几二十万条吧),关键是整个过程中要交换多少信息呀,整网一旦发生拓扑变动,比如某条物理链路中断,这个路由要稳定下来需要多久呢?

    结论:有些时候最简单粗暴的办法,反倒可能是最有效的办法。10万台服务器无阻塞的千兆接入,用现有的设备+万兆端口是搞不定,但是如果设备进化,全换成100G端口呢?又或者,虚拟机全部大行其道,进而服务器的硬件变得非常的彪悍,使得物理服务器的数量大幅度减少,也可以解决这个问题,原本需要10万台服务器才能搞定的,现在也许只需要1千台。

  66. 请教 于 2011-03-24 2:33 上午

    to nexus:
    同意低时延和cut through不是划等号的。
    关于MAC表容量大小,这也是我认为J的方案由于C的方案的地方。
    关于ARP表,想请教,这个必须看到VM的虚MAC吗?如果是这样,恐怕跟fabric的方案就没多大关系了,集中式的三层设备肯定会是痛点,业界有没有分布式三层设备的组网方案考虑?

  67. Soulhacker 于 2011-03-24 3:57 上午

    是我表达的不够清楚。Fabricpath,vPC和PC的目的一样是用来消除2层网络下的STP增加可用带宽的。

  68. Da Vinci 于 2011-03-24 5:38 上午

    看的过程中,感觉越看越像TRILL,最后看到结论,果然是TRILL的一个变种。既然硬件
    平台能够完全支持TRILL,那可优化的地方就有限了。这里列了一些问题,期待libing
    或其他的牛能够解答。自己不是搞DC的,只是看过一下TRILL的draft。
    1。“基于会话的MAC地址学习”,觉得这个似乎不能有太大的改善。首先,对于一台
    FPswitch,如果local的网络刚刚启动,还没有学到多少本地MAC的时候,从FP过来报文
    的目的MAC完全可能查不到,这样就不进行学习。此时local的设备向FP用这个没有学习
    到的MAC做DA发报文,就会变成广播。当然,这个可以通过上层应用来解决。其次,如
    果FPswitch收到广播报文学不学?期待这里有什么精妙的办法来解决。
    2。还是MAC学习,呵呵。其实TRILL里边也对MAC学习做了优化,可以通过ESADI的协议
    报文来学习远端的MAC,而不是通过数据报文。但是这样就导致了协议的负担,还带来
    了multicast的问题。不知道FP里边有没有这个,不过这个是软件行为,升级起来容
    易。但关键硬件要能够识别。
    3。组播问题。TRILL里边的组播是很麻烦的,感觉违背了网络分层的原则。在接入设备
    上,当然需要考虑用户的信息。但是在核心转发设备上,基于TRILL header转发的时
    候,还需要关注内部的用户VLAN和MAC,这样的层次感不够清晰。不知道Cisco的FP是不
    是也一样?TRILL里边如果能够处理好组播的问题,感觉还是很不错的东东。看libing
    给的那个Cisco的链接,组播的内容讲的比较少?也可能俺辽文不够好,没看懂,^_^
    4。组播里边的FTag。组播/广播组都是由这个field决定的?但是这个只有10bit,整个
    网络的组播组有限啊。
    5。FP的header前边还有其他的二层链路协议头吗?看Cisco的描述似乎是没有。难道就
    直接FP header这样裸跑的?如果没有其他二层头的话,那只要用FP的网络整网都得用
    Cisco的设备,这一招够狠啊,呵呵,但也体现了Cisco的信心。
    6。Cisco自己的ASIC是不是做了两套parse,一个做FP,一个做TRILL。哈哈,猜的。前
    边Sting说Cisco用broadcom的芯片,是不是Trident系列?Trident里边已经有TRILL这
    些DCB的feature支持了。但是觉得有点像吃螃蟹,呵呵,BCM的DCB feature之前好像没
    有谁用过啊。另外,看到FULCRUM的FM6000似乎支持的DCB东东也蛮不错的。有没有哪位
    牛来掰一掰。

  69. Da Vinci 于 2011-03-24 5:39 上午

    编辑坏了,重贴,不好意思。

    看的过程中,感觉越看越像TRILL,最后看到结论,果然是TRILL的一个变种。既然硬件
    平台能够完全支持TRILL,那可优化的地方就有限了。这里列了一些问题,期待libing
    或其他的牛能够解答。自己不是搞DC的,只是看过一下TRILL的draft。
    1。“基于会话的MAC地址学习”,觉得这个似乎不能有太大的改善。首先,对于一台
    FPswitch,如果local的网络刚刚启动,还没有学到多少本地MAC的时候,从FP过来报文
    的目的MAC完全可能查不到,这样就不进行学习。此时local的设备向FP用这个没有学习
    到的MAC做DA发报文,就会变成广播。当然,这个可以通过上层应用来解决。其次,如
    果FPswitch收到广播报文学不学?期待这里有什么精妙的办法来解决。
    2。还是MAC学习,呵呵。其实TRILL里边也对MAC学习做了优化,可以通过ESADI的协议
    报文来学习远端的MAC,而不是通过数据报文。但是这样就导致了协议的负担,还带来
    了multicast的问题。不知道FP里边有没有这个,不过这个是软件行为,升级起来容
    易。但关键硬件要能够识别。
    3。组播问题。TRILL里边的组播是很麻烦的,感觉违背了网络分层的原则。在接入设备
    上,当然需要考虑用户的信息。但是在核心转发设备上,基于TRILL header转发的时
    候,还需要关注内部的用户VLAN和MAC,这样的层次感不够清晰。不知道Cisco的FP是不
    是也一样?TRILL里边如果能够处理好组播的问题,感觉还是很不错的东东。看libing
    给的那个Cisco的链接,组播的内容讲的比较少?也可能俺辽文不够好,没看懂,^_^
    4。组播里边的FTag。组播/广播组都是由这个field决定的?但是这个只有10bit,整个
    网络的组播组有限啊。

    5。还是组播问题,呵呵。FP是不是要像TRILL那样先基于FP header做一次组播转发,
    如果有本地成员的话要剥掉FP header,基于内层header再做一次组播的转发。真的是
    麻烦的,连broadcom在实现这个的时候都要把在芯片里边转来转去的才能发出去,真的
    头大的。

    6。FP的header前边还有其他的二层链路协议头吗?看Cisco的描述似乎是没有。难道就
    直接FP header这样裸跑的?如果没有其他二层头的话,那只要用FP的网络整网都得用
    Cisco的设备,这一招够狠啊,呵呵,但也体现了Cisco的信心。
    7。Cisco自己的ASIC是不是做了两套parse,一个做FP,一个做TRILL。哈哈,猜的。前
    边Sting说Cisco用broadcom的芯片,是不是Trident系列?Trident里边已经有TRILL这
    些DCB的feature支持了。但是觉得有点像吃螃蟹,呵呵,BCM的DCB feature之前好像没
    有谁用过啊。另外,看到FULCRUM的FM6000似乎支持的DCB东东也蛮不错的。有没有哪位
    牛来掰一掰。

  70. Da Vinci 于 2011-03-24 5:40 上午

    Cisco为什么既积极参与TRILL的标准化过程,还要自己搞一套私有的东西?我认为这个
    还是从商业上的一个考虑。标准化是多方角力的一个过程,远没有搞自己私有的东东来
    的快。所以肯定不能等到标准成熟再来玩,那时候就没有优势了,反而是给他人做了嫁
    衣。但是,也不能一开始就说支持TRILL,否则后边改来改去怎么玩。
    所以只要转发面上定下来之后就可以完全自己去搞一套东西。虽然声称是私有的,但是
    其实和标准应该不会有太大差别。先靠这个占领市场,然后在TRILL标准化的过程中极
    力往自己的私有标准上靠。等到标准成熟了,户发只要升级软件即可。当然啦,这里再
    收点费也是情理之中嘛。对于急需升级或者新建数据中心的用户来说,这样的确也能最
    大限度的保护投资。

    相对于VPLS,TRILL和FP都没有解决接入设备上MAC地址过多的问题。TRILL和FP只是完
    全抛弃了IP。VPLS从本质上来说还是属于IP的东西。至于说到IP/MPLS多么多么的复
    杂,是的,这里是比较复杂。要full mesh,水平分割,要有路由协议,要有标签分发
    协议。虽然要求很多,但是一旦一个网络部署起来后,场景也就固定了,只要那么几种
    协议跑起来就ok了。TRILL/FP感觉也不会简单多少(特别是组播的问题),也有不少已
    知和未知的问题需要各种各样的扩展去解决。反而是在MPLS里边,如果更多的是点对点
    的应用,可以用VPWS,没有了learning,也就简单很多了。而VPLS由于是full mesh,
    可以很好的解决组播的问题,缺点当然是牺牲了带宽。
    个人感觉这里还是商业利益的问题,认识比较粗浅,欢迎拍砖。要不然也不会有
    802.1aq再来搅和了。谁都不愿意输在起跑线上嘛。倒是可怜了这些系统厂商,两手都
    要抓,两手都要硬。不过802.1aq却有很好的leverage,可以沿用已经部署的PBB,还天
    生附带OAM(PBT),而OAM这个东东TRILL里边根本没有考虑,相信FP也没有。但是大家
    都在说PBT is dying,但是IEEE也不愿意束手就擒啊,只要没有大规模得到用户的认可
    那就还有机会。真的乱了,看不清后边的情况,只是在痛苦的看资料。不知道以后会不
    会像IETF和ITU为了TP吵得一塌糊涂一样。呵呵,俺只是痛苦的看客。

  71. ZC 于 2011-03-24 5:52 上午

    延迟和拥塞应该怎么考虑?

    一个交换机不可能只接一台PC,那么多mac占用多条链路肯定比单链路有效的多。

    如果只考虑但路径,拥塞出现之后,链路结构本身造成的延迟就是第二位考虑的了吧。

  72. libing 于 2011-03-24 7:41 上午

    to davinci

    谢谢你的关注,你的问题很长,我归纳起来回答

    关于MAC:对于未知目的MAC地址的帧,只能通过广播学习,这个过程同原有二层行为类似,但是,对于一般的广播包,FabricPath网关是不会学习源MAC地址的。如果你拿这个行为比较一个传统的二层网络,你会发现,在传统二层网络里面,交换机只要接收到数据帧就会学习地址,这些地址很大一部分是没有用的,这也是导致虚拟化环境中接入设备MAC地址表撑不住的原因。FabricPath杜绝了这种“没有目的”的学习行为,以此来减少MAC地址表大小。
    回到你的问题,当FabicPath网关的MAC表里没有目的地址时咋办,很简单,还是会把帧以类似广播的行为送到远端。如果想控制MAC地址表大小,这一步是省不掉的,至少目前没有更好的办法。

    关于组播:组播信息在FabricPath网关处会被处理成一个新的IS-IS LSP通告到出去。当组播进入FabricPath网络时,被分配对应FTag和目的switch ID,在整个网络内,根据这两个信息进行路由。
    10个bit你觉得少了?我觉得还成。当然,如果达到了FabricPath的上限,有16台满配的汇聚交换机,和无数VLAN,以及大量组播组,可能紧点,任何技术都有极限。

    CISCO做FabricPath的目的,我非常同意你的观点,这是Cisco的一贯风格

    欢迎继续拍砖:)

  73. jiaruifu 于 2011-03-24 8:10 上午

    三层过来的流量在FabricPath二层网络内部只能是单路径转发,即点对点。

    主机从FabricPath二层出去到三层的流量最多是二倍单路径的关系,不存在任何其他二倍以上的多路径。

    这样看FabricPath对南北方向的拥塞并不产生什么决定性的影响。

  74. 理客 于 2011-03-24 8:47 上午

    请教一个外行的问题:
    1、DC的业务是否使用TCP/IP?
    2、如果是,使用L3/MPLS SWITCH有什么问题?是成本问题还是技术问题?是可靠性、收敛慢、时延…

  75. ABC 于 2011-03-24 7:03 下午

    楼上,从LZ的文章来看。端还是要使用IP的,不过随着FCOE的介入可能未来IP不是必须的,即L3在DC中不是必须的。
    但是目前来看,L3在DC中需要简化和弱化,因为DC中更多的流量是“横”向的,而L3则会增大数据转发的距离以及时延。会带来用户体验的下降。

  76. ZC 于 2011-03-24 7:44 下午

    继续学习讨论,如果所谓南北流量是要跨越三层的话,那其实不是FP关心的吧?

    感觉FP主要是为了解决原有SPT交换网的效率,因为最终思科是希望建立一个以交换为核心的DC,FCoE就是为了把主机和存储之间的通讯都通过交换机完成。

    FP应该主要解决的是一个二层平面内所有主机/存储/虚拟机之间的流量交换。

    另外,即便三层进来的流量,只要不是针对同一台主机,就存在点对多点的流量。

  77. ZC 于 2011-03-24 8:25 下午

    当然,现在juniper攻击trill的说法,就是“TRILL是一个寻找问题的解决方案和扩展二层网络的方法,但是,大多数数据中心网络要在三层进行通信。三层被局限于一个单臂路由器并且成为一个瓶颈。TRILL适用于数据中心是一个笑话。”

    弯曲哪位高手给讲解一下Qfabric,Trill,SPB之间的异同啊,ms是今后交换市场的主要竞争协议哦。

  78. ZC 于 2011-03-24 8:27 下午

    Trill和SPB起码还有公开的草案,qfabric是不是完全封闭的专利?

  79. libing 于 2011-03-24 8:35 下午

    to jiaruifu

    在存在多个三层网关的情况下,上联路径的设计可以非常丰富的,不限于两条。

  80. libing 于 2011-03-24 8:37 下午

    to ZC

    Qfabric目前看起来是个封闭的环境

  81. jiaruifu 于 2011-03-24 8:54 下午

    To libing:

    你说得对,但是多个网关会是一个什么样的拓扑结构了?这会与DC外围有很大关系,但一般情况下会是两条。
    进出网关的流量拥塞是可以通过你所说的vpc轻松解决的。个人感觉部署两条以上的可能性应非常非常小。
    你是cisco技术专家吧,对这个研究很深刻啊。

  82. libing 于 2011-03-24 8:56 下午

    to jiaruifu

    北向流量在FabricPath网络内可以有多个路径,对于视频点播等大流量业务,还是不错的。
    任何技术都是有代价的,FabricPath增加了帧头的开销,但是解决了数据中心扩展性的问题,我认为值。

    在我看来,FabricPath最大的问题,是近期有多少用户会真正愿意部署它,快速的产业化是Cisco在FabricPath上最大的挑战。

  83. ZC 于 2011-03-24 8:58 下午

    关于qfabric,认同57楼nexus的观点,“QFabric作为封闭的交换机集群的设计思路,可能有个别客户采用,大多数用户还是会采用开放的,标准的技术和设备。”

    juniper认为,QFabric“改变了以太网交换机的扩展模式”,这种扩展是向分布式和联邦制单元扩展,而不是扩展成多台以太网交换机。通过“重新考虑数据平面、控制平面和管理平面,QFabric可扩展到6000多个端口和每秒44TB的横截面带宽,同时又保持单台交换机的运行模式。”可以想象多家厂商的产品组成单台交换机的运行模式么?呵呵

    没有人愿意被绑定/架在某个厂商,qfabric有点像当年的eigrp,最终还是用ospf的人多,:)

    拭目以待吧。

  84. ZC 于 2011-03-24 9:07 下午

    to 82楼 是啊。

    FP增加了帧头的开销,同时引进了多/全路径的同时转发,这应该就是考虑了二层平面内拥塞和延时的平衡,提高整体转发效率。

  85. jiaruifu 于 2011-03-24 9:09 下午

    To libing:

    一般情况下对南北向流量转发在二层网络内的价值不会超过两倍,但是什么时候二层网络的拥塞会成为三层路由模式下的传输瓶颈了,如果有二层拥塞,用vpc就可以了解决了。
    但是二层的延时损失却是显而易见的,任何转发技术在二层网络内都不应有这样的忽略和闪失。

  86. ZC 于 2011-03-24 9:20 下午

    To jiaruifu

    VPC应该是双上联的解决方案,但不是full mesh的解决方案。

    VPC ms不能替代trill吧。

  87. 旁观者清 于 2011-03-24 9:23 下午

    拒绝广告

    完全变成了思科闲人们的广告空间了!!! 哈哈哈

  88. jiaruifu 于 2011-03-24 9:31 下午

    To ZC:

    看不清楚啊。
    不付出任何代价要解决STP这个问题看来是很困难的。

  89. 旁观者清 于 2011-03-24 9:32 下午

    弯曲现在居然演变成了某些大公司的闲人们发布广告,对不了解内情的人进行洗脑的平台了。

    也许可以开发一下,收些平台使用费增加些运营经费了,呵呵

  90. liqiangln 于 2011-03-24 9:41 下午

    兄弟是做硬件的,对我来说,我看到的就是用光纤/高速cable搭建一个mesh/clos之类的Fabric背板,通道之间打上自己端口识别的Fabric标记,形成一个无阻塞的传递方式。

  91. ilovebgp4 于 2011-03-24 11:08 下午

    90楼 liqiangln说的似乎是J的QFabric

  92. 理客 于 2011-03-25 1:06 上午

    没有这方面的基础知识,还是不太明白使用L3转发在DC中代替交换机的L2转发,会对时延造成很大的影响。是不是DC和存储中的一些协议不支持L3,只支持L2?

  93. zeroflag 于 2011-03-25 1:43 上午

    to 92:

    DC之所以选择二层而不是三层,我了解到的最核心的原因是为了虚拟机的迁移。当DC全面虚拟化以后,虚拟机应具有快速的在整个数据中心的物理服务器上进行迁移的能力。比如一台物理服务器服务器上的CPU或者I/O资源不够的时候,会将这台物理服务器上的某个或某几个虚拟机迁移到别的服务器上,以保证虚拟机的性能。但是在虚拟机迁移的过程中,如果DC是基于IP三层网络,那么网络管理员在每次迁移的时候都要在汇聚层交换机上重新配置IP路由等一堆的网络策略,而虚拟机的IP可能也需要改变,造成业务中断,最终造成虚拟机根本无法灵活的迁移。总之是个很脏的活。如果是二层组网则没有类似的问题。

    Trill和FP解决的是DC的网络核心如何适应二层组网(并且在10万台以上的服务器无阻塞组网时才有价值),而现在搞的VN-TAG和VEPA则是为了解决网络如何感知到虚拟机的迁移。

    新的数据中心以太网技术,最重要的部分差不多都是围绕虚拟机的迁移的需求进行的。当然也有围绕高性能、低延迟、无丢包的需求,例如VSS和IRF2,不过那些都是私有的,不是重点。

  94. kernelchina 于 2011-03-25 2:39 上午

    新的DC,还关注存储和计算用同一个网络:以太网,简化拓扑,降低部署成本。如果都是二层,安全怎么办?怎么保证流量不会bypass安全设备,或者安全设备也要参与到L2的网络当中?

  95. 理客 于 2011-03-25 3:19 上午

    感谢zeroflag的解释,确实是有问题。用VPLS解决如何?

  96. libing 于 2011-03-25 8:16 上午

    to jiaruifu

    我并不认为FabricPath是解决南北拥塞问题的最好方法,如前所述,FabricPath的初衷是解决东西流量的瓶颈和数据中心的二层平滑扩展,在这个过程中,确实带来了新的帧头开销,任何技术都有代价。
    在进行数据中心设计时,要考虑各方面因素,最终选择一个最适合的方案,对于大部分快速扩展的虚拟化数据中心来说,FabricPath是有帮助的。在这种情况下,FabricPath带来的开销是可以忍受的。况且,FabricPath对南北流量也有优化,设想这样一种情况,我们可以在汇聚层设置多于三个三层网关,对应不同的从数据中心出去的业务数据,多于两个的链路并不是坏事。如果使用VPC,这种设计就不可能。FabricPath的新特性可以带来很多新的思路,使我们在设想一个数据中心网络时不再拘泥于原来的思路。

  97. jiaruifu 于 2011-03-25 9:15 上午

    To libing:

    谁有juniper的qfabric的材料我们先分析再来下结论吧。

  98. ipneter 于 2011-03-25 8:45 下午

    文章非常不错,如果能从数据发出导数据接收整个转发过程一步一步的将数据结构图示出来,就更容易理解了。
    好文章还是要多学习的。

  99. sclzyb 于 2011-03-28 6:54 下午

    能不能有哪位大师比较一下SPB与trill的区别啊

  100. libing 于 2011-03-29 7:59 上午

    SPB和TRILL的区别google上有不少
    这有一篇中文报道比较有意思:http://www.bitscn.com/network/protocol/201103/192930.html

  101. metal1011 于 2011-03-29 1:27 下午

    网络工程师

    狂热的培训

    悲剧的薪水

    3点的行业

  102. Tech 于 2011-03-29 8:04 下午

    请大家在讨论的时候,不要忘了是在DC中,DC中三层IP使用的少,二层使用的多。业务流量模型影响互联架构,互联架构影响技术的使用范围。说到安全性,一个一个交换机难道就安全了,MPLS和VPLS提供的广域网的穿越服务,服务的场景不同,在一个DC的机房,直接连纤(连线)就可以,何必用这些广域的技术呢。

  103. ABC 于 2011-04-01 1:45 上午

    重新拜读大作,突然有个问题,思科搞了半天,在MAC帧中加入了switch id,同样是最多支持4K。那么现在的vlan id是否能用?这样当前交换机是否可以很easy的实现switch id的特性?

  104. libing 于 2011-04-02 4:44 上午

    to ABC

    Switch ID用来表示一个节点,和VLAN的含义不同,重用的困难应该不小

  105. ABC 于 2011-04-02 9:30 下午

    lz,含义这个东西是人为定义的。深入一点,qinq可以做两层标签,switch id也只有一层。lz觉得困难在?

  106. fastpath 于 2011-04-05 7:22 上午

    http://www.lightreading.com/document.asp?doc_id=206394
    SPB的支持者也来了,lightreading的题目就叫:
    AlcaLu Wants the Data Center, Too

  107. libing 于 2011-04-07 4:25 上午

    To ABC

    VLAN的含义是隔离不同类型的数据,往往和业务挂钩,复杂一点的地方还有私有VLAN,一个端口上还可能有多个VLAN,要复用VLAN来实现选路,我粗略一想就觉得挺复杂,你以为呢?

  108. ABC 于 2011-04-07 6:30 下午

    如果是即保留vlan特性,还要增加DC特性,这种复用会比较复杂。

  109. tree 于 2011-04-10 8:37 上午

    我想问一下思科的朋友,在FabricPath最佳实践中,一个IDC那么多服务器的网关部署在什么位置?
    1. 如果是在核心上,是不在2~4个或者更多核心之间使用GLBP?“我觉得这个好像更可行一些“
    2. 如果专门再找1个单独的上行设备作为网关,这个网关讲维护大量ARP类的表项,对设备要求也挺高的,并且1个设备也容易有单点故障,是不是也是要2个又做一下GLBP?

  110. Andyfly 于 2011-04-13 1:54 上午

    真热闹呀! 大拿真不少呀,一定要常来! 最近在学习思科的相关方案,真的很有帮助!

  111. a123 于 2011-04-13 7:54 上午

    如果只是为了解决生成树和数据中心平滑扩展的问题,没看明白Cisco的FabricPath比 H3C推的IRF技术有何优势?

  112. a123 于 2011-04-13 8:14 上午

    本文写得非常好,但是为何没有提及Cisco VSS技术也能解决L2中的生成树问题?

    为何一定要劳师动众,用全新的FabricPath来代替VSS技术?

  113. zeroflag 于 2011-04-13 8:15 下午

    to a123:
    不是一个类型的东西,差异非常大。我的理解是这样的:

    虽然都是解决STP链路使用效率低,不适合全冗余组网的问题。但是两类技术的实现思路差异很大。

    TRILL也好,FabricPath也罢,其实现可以简单理解为多台设备之间的以太网路由。用路由替代STP的好处是,可以用等价路由将多条链路的带宽都利用起来,而STP必须阻塞掉除一条链路外其余的所有链路。所以新方案比STP带宽利用率更高,可以完全替代STP。也即启用了TRILL后,就不需要启用STP了。

    VSS和IRF则是将多个设备虚拟成为一台设备,然后顺理成章的可以实现跨物理设备的链路聚合。由于将多条链路捆绑为一条链路,故此也就不存在所谓的冗余链路,也不会形成环路,STP尽管存在,但是不会工作。所以VSS和IRF只是一种规避的方案,并不能替代STP的使用。

    两种实现在外在表现上,最大的区别是组网规模不同。

    IRF和VSS一般组网不能超过2太,H3最新的10500貌似有了突破,好像也只能达到四台。这个限制主要应该是受限于引擎的性能。这决定了组网核心层的设备数量和扩展能力。

    而TRILL不存在这个问题,只要路由表条目够,核心层设备的数量基本不受限制。因此具有更好的扩展性,再加上公开标准的互操作性,允许多个不同厂家的设备互联,也可以极大的降低成本。

  114. zeroflag 于 2011-04-13 8:18 下午

    另,Cisco的N7K并不支持VSS。这里面固然有新收购的N7K并不适用IOS的原因,但是Cisco似乎并不没有打算改变这一点,那么是不是可以认为,Cisco已经放弃了将VSS用于数据中心组网的技术路线?

  115. a123 于 2011-04-14 8:15 上午

    多谢zeroflag,看来我猜对了。

    其实VSS,IRF在中小型数据中心挺好的:)

  116. zeroflag 于 2011-04-15 5:23 上午

    to a123:
    我根据H3 S12500的最高端口密度计算过,用IRF2做两台S12500的虚拟化以后,可以无阻塞的最多接入2880个千兆网卡(8×18×10×2)。有收敛比的时候另说。

  117. mll 于 2011-04-15 7:25 上午

    大二层的解决方案目前已经出现了多个,cisco是起步比较早的,这就是领头者的风范。
    华为目前也在参与spb。

  118. kernelchina 于 2011-04-15 7:59 上午

    随便说几句,错了别拍啊
    1)路由的树是以自己为顶点;而STP的树是以ROOT为顶点,路由的树结合RPF check可以避免loop,不需要把某个端口禁掉,所以比STP要好一点。但是哪个收敛速度快,没有一个明确的概念。
    2)VSS, IRF是把多个变成一个,控制平面是一个;而Fabric-path, TRILL是多个组成一个网络,是分布式的,有多个控制平面,每个只负责自己的事情。
    3)VSS, IRF之类的解决方案对控制平面的性能要求很高,容量也要求很高。端口多了,想集中管理,难度不小。

  119. libing 于 2011-04-15 7:42 下午

    To zeroflag

    您说得不错,FabricPath是大规模组网的解决方案。
    另外,在N7K上有类似VSS的技术,叫vPC,但其规模限制在两台。由于VSS/vPC的实现在很大程度上依赖心跳信息,以及对心跳信息的处理,在规模扩张上有瓶颈,这就好像ORACLE RAC大部分也就是搞搞双机,如果还要扩张数量,难度成不是线性增加。
    而FabricPath瞄准的是大二层需求下,大量交换机的组网方案,这个时候就必须要有一个控制平面来协调不同节点之间的交互,如果说VSS/vPC是简单的神经反应,FabricPath则好像一个“能够思考的大脑”,打通了大规模组网的障碍。
    我觉得基于VSS/vPC或IRF的思路增加交换机数量,后期难度会非常大。

    To kernelchina

    STP在收敛和稳定性上,同路由的差距还是不小的,他的优点就是低成本、简单。

  120. ABC 于 2011-04-15 10:37 下午

    irf说到底还是堆叠的进阶,在统一管理上是有优势的,但还针对的是系统设备。fp可以理解为一个协议,无所谓系统。可以说fp的发展比irf要清晰一些。在dc这个市场中,fp比irf要看的长远。
    不过irf在未来开放出来,未尝不是个好的选择。

  121. longdas 于 2011-04-22 5:24 下午

    学习中,感觉就是剪裁了的mpls工作在二层

  122. yangyongqiang 于 2011-05-03 2:02 上午

    感觉和TRILL是差不多,不过cisco应该对TRILL和SPB都有参与吧~
    我觉得SPB在流量管理和现有硬件支撑方面很有优势啊,不知道为什么cisco选择对TRILL进行改进,不选择SPB呢?

  123. igp2bgp 于 2011-05-12 11:50 上午

    形如交换机,
    神似路由器。
    朝思即插拔,
    暮想零配置。

  124. Bright 于 2011-07-14 8:50 下午

    作者写的很棒,底下讨论的也很精彩,云计算/虚拟化势必带来整个产业链相关的技术的整体洗牌和升级,让我们拭目以待。
    :-)

  125. seachb 于 2011-09-26 1:23 上午

    看了文章和下面的评论,非常精彩!
    有个小疑问,不知道楼主或者哪位大侠能不能帮忙解答一下:有什么应用需要用到FabricPath或者OTV等技术?数据中心的虚拟化真的需要跨越大的共有3层网络吗?如果这样,时延能够保证吗?

  126. cesar 于 2011-12-19 5:12 上午

    回11楼:
    虚拟交换机是多虚一,不是一虚多。交换机只是越虚越少。
    switch ID只有4094,应该也够用了,一个二层网络里超过4094台,那网络得有多大啊。广播一下都不得了。

  127. wei 于 2012-09-25 2:14 上午

    根本不相干 于 2012-06-29 8:11 上午
    其实,简单问题复杂化一向是网络工程师喜欢干的事情

    对小规模网络,原来怎么用vlan,现在还怎么用
    ,只不过原先是在access switch的
    untag端口加,现在是vswitch加。然后host和switch之间运行普通的trunk协议即可,该怎么玩还怎么玩。vlan数不够?对大多数中小企业这句话是个笑话。顺便补充下,目前主流网卡都支持tag/untag卸载

    大规模网络,包括IDC在内,二层是行不通的,802.1AQ/Trill大二层已经证明是个笑话,不然Vmware不会再和cisco搞vxlan,微软也凑热闹弄个nvgre,再加上OVS支持的那几个tunnel方式,核心思想无非一点:L2 over physical L3仿真实现flat L2,而不是大的physical L2,这样把复杂性全部推给了end point。

    下面讨论性能、管理等问题

    以上内容是 下一代数据中心的虚拟接入技术–VN-Tag和VEPA 中的一条讨论回复

    大二层真的不可行了?