数据中心分解实验(五)--abricPath

这个实验有点长,看官慢慢看!

传说中用来取代生成树(Spanning-tree)的FabricPath(这个还真不太好翻译,就简称FP吧),到底是啥?先别急,首先回顾一下生成树协议,作为二层网络的防环路机制,生成树确实有积极的一面,不过缺点也是一大堆啦:

1.    收敛很慢,论秒计的速度;

2.    运算机制也比较复杂,配置管理和维护也相对复杂;

3.    网络里有接口被BLOCK,才能形成无环路的树;

在数据中心网络里,这些缺点都会进一步被放大,设想:一台服务器连接到网络上,需要若干秒才能开始转发数据,这个速度太慢了;一个巨大的二层网络的生成树维护,想想也是醉了的;花了大价钱买来的10G、40G甚至是100G端口,却被置于BLOCK状态,那可真是叔可忍婶儿也不能忍啊!

小小的吐槽了一下生成树,当然是为了显示出社会主义制度,哦,不对,是FabricPath的巨大优越性:

1.    收敛速度大大加快,FP的底层协议是ISIS,ISIS作为一个路由协议的收敛速度可以达到毫秒级;

2.    虽然原理并不那么简单,不过配置起来那就… 哈哈哈,容我大笑五分钟;

3.    一个二层网络,居然不用BLOCK任何端口也不会产生环路,好神奇,对比生成树,最起码带宽的利用率高了不少;

实验逻辑拓扑:

实验目标:四台设备互联的标记为绿色的线路上运行FabricPath协议

如果不是运行FabricPath,这样一个二层网络如果不BLOCK掉一部分接口,那环路是不可避免的了,接踵而来的就是广播风暴,最后网络瘫痪,这里用了FabricPath,情况就完全不一样了~

Showtime,实验开始

第一步,允许设备运行FabricPath

DefaultVDC里开启FabricPath这个特性集,然后到需要运行FP的VDC里去开启FP

N5K也类似,

第二步,定义FP模式的VLAN,

可以看出VLAN的模式有两种CE和FabricPath,关于这个模式是啥意思,最后详细说明下 (每台设备上配置VLAN的方式是一样的,我这里就只贴一个图了)

第三步,把互连接口配置成FP模式

好吧,事情发展到了这个地步,我必须告诉你们,FP的实验已经做完了…

邻居建立成功,控制层面开始计算,生成FabricPath路由表和MAC地址表之后,数据层面该怎么转发就怎么转发啦~

FabricPath的基本操作就是这么简单,

细心的同学可能会问,为啥两台N7K之间的链路没有运行FabricPath呢,这个留个大家去思考一下咯?小提示,结合实验一里面的“主干、枝叶”结构去思考~

根据以上实验,补充一些关于FabricPath的知识点,不关心理论的,请直接忽视啦

传统生成树网络中,Server A要访问Server B,过程是这样的:基于数据帧头部里的Destination MAC信息,ServerB的MAC地址是MAC B

帧头部包含的信息


Destination MAC

(MACA)

Source MAC

(MACB)

… …

DC2-N5K-1交换机上去查CAM表

设备 MAC 端口
DC2-N5K-1 MAC A E1/15
MAC B E1/21-22

通过E1/21-22转发给DC2-N7K-3,

于是,逐跳逐跳的,数据帧从DC2-N5K-1 -> DC2-N7K-3 ->DC2-N5K-2 最后到达Server B,是传统网络中的二层交换过程。其核心的思路是转发是逐跳的,每一跳都要根据地址进行表项查找,这种执行效率是比较低下的。

FabricPath原理相对于二层交换,非常类似于MPLS相对于传统路由的关系,FabricPath在原有数据帧的前面增加了一个新的二层头部(MAC in MAC),于是网络的选路不再基于MAC信息,而是基于新头部中的信息 - - - Switch ID。

FP网络中每个节点都有一个唯一的Switch ID(类似于路由协议的router-id),协议会分配,也可以手工指定Switch ID,但必须保证唯一性;FP的底层协议是IS-IS,IS-IS根据Switch-ID来做二层路由计算,在二层路由中用到的表项有两个FabricPath IS-IS路由表、 FabricPath路由表和mac address-table,

FabricPath IS-IS routing table,到任何一个Switch-ID应该从哪个接口转发,

例如下图红框:60是通过Port-Channel200可达,

Mac address-table,除了MACVLAN 等信息之外,还有SWID/SSID/LID,例如40/0/210

SWID Switch-ID,FabricPath环境中设备的标识符,必须唯一不冲突
SSID SubSwitch-ID,没有vPC+,这个值始终为0
LID
FabricPath头部里的Port-ID,用来标识交换机上的具体接口,

(这个值看起来会很奇怪,不过交换机知道是指的哪个接口啦)

那么这个时候,Server A 到Server B的访问是怎么样的呢?

首先,数据帧到达DC2-N5K-1之后,会被加上一个新的FabricPath 头部

<---           Outer DA           --><---           Outer SA           -->

Switch ID Sub Switch ID Port ID Switch ID Sub Switch ID Port ID Ftag ......
40 0 4306 30 0 4306 1

从进入FabricPath的域开始,设备的路由都是基于Switch ID,所有Switch ID该如何到达,在FabricPath路由表和FabricPath IS-IS路由表里可以查到。

并且数据包是直接要求发送往具体某个Switch ID上的某个PortID对应的接口的,End-to-End的方式,(非常类似于MPLS的标签查找,完全区别于基于MAC的逐跳查找)

最后我们来看看,FabricPath跟vPC强强联合的情景吧,这种工作场景被称之为vPC+(一般的vPC的二层网络都是运行Spanning-Tree生成树协议的)

vPC跟FabircPath两个家伙,想要一起工作,除了前面实验四里面演示过的vPC配置和实验五上半部分介绍过的FabricPath配置之外,vPC的配置要做如下改动

FabricPath工作在vPC+的环境下只所以有些特殊,原因是:SwitchID跟设备应该是一一对应的,但是vPC的Peer Switch两台可以看做是一台设备在工作,所以,

有vPC+的情况下,vPC的PeerSwitch会增加一个虚拟的节点,这个节点有一个虚拟的Switch ID,称之为VirtualSwitch ID。

接入层Switch通过vPC20发送数据,目的地址不是DC2-N5K-1或DC2-N5K-2的Switch ID,而是这两台PeerSwitch虚拟出来的Virtual Switch ID,至于这个流量是从Port7发送还是Port6发送,这个会HASH算法运算之后进行负载均衡。

当数据要发往Switch的时候,情形也类似,数据包的目的地址其实是而是这两台PeerSwitch虚拟出来的Virtual Switch ID,数据包到底是从DC2-N5K-1还是DC2-N5K-2走?其实是谁都不重要,最终都会从vPC PeerSwitch共同管理的vPC20走,至于最终是哪台设备来做处理,会用HASH算法计算后做负载均衡。

FabricPath IS-IS routing table,会增加一个virtualSwitch ID的条目

Mac address-table,除了MAC、VLAN、老化时间等信息之外,还有SWID/SSID/LID,例如: 70/0/0

Mac address-table,除了MAC、VLAN、老化时间等信息之外,还有SWID/SSID/LID,例如: 70/0/0

SWID vPC+环境里,是vPCdomain里配置的virutal Switch-ID
SSID
用来标识vPC+下的一个Port-Channel,

可以这么理解,在vPC+环境中,这个值标识出接口,只不过这个出接口是个virtualPort-Channel

LID 无意义

时间: 2024-12-18 01:35:24

数据中心分解实验(五)--abricPath的相关文章

数据中心分解实验(二)--“初见N7K”

啦啦啦,好汉们,又见面了,罗嗦了一集"7 5 2"之后,今天是带你玩弄DC的第二个实验 -"初见N7K".(人生若只如初见?我呸,这样岂不是一辈子不能将N7K玩弄于股掌之间了吗!) 首先,啥是N7K,N7K是Nexus 7000的简称,在思科的产品结构里面,7系列的产品有两款,Nexus 7000和Nexus 7700,主要区别体现在性能上. (其实思科挺背的,我们最熟悉的Nexus应该是谷歌出的Nexus系列的平板和手机,另外对于思科的IOS来说,我们最熟悉的IO

数据中心分解实验(七)---OSPF EIGRP

这个实验里面,我们继续来看看数据中心网络中的路由协议有什么特别之处呢,好吧,答案跟FHRP一样,其实在数据中心的OSPF和EIGRP的部署与常规网络里几乎是没有区别的. 为啥不讨论RIP和BGP?基本上是因为RIP比起OSPF跟EIGRP起来,是毫无优势可言,满满的都是劣势啊,而BGP通常应该部署在大网中(大网类似于运营商的网络啦又或者是跨国公司的广域网啦),所以呢,这里我们就不讨论BGP的问题了. 对于目前主流的数据中心来说,内部的网络是二层的,网关和路由通常部署在网络的边缘,这里有两种不同的

数据中心分解实验四--PC和VPC

OK,I am Back.实验3学习了N5K并简单的回顾了Port-Channel,继续介绍数据中心里面的一项新的技术 ---vPC(virtual Port-Channel),虚拟的链路捆绑.前面我们提过Port-Channel的两端是一台物理设备,那vPC两端呢,那就不一定啦,经典的vPC环境如下图所示:一端为DC2-N5K-1和DC2-N5K-2组合成的逻辑实体(一个vPC Domain下的两台vPC PeerSwitch),另一端为DC2-N2K-1. 实验逻辑拓扑: 上个实验里面我们已

数据中心分解实验(三)-N5K

经过上次的实验,我们了解了下N7K之后,今天要继续了解75 2构架里的N5K. 对比起N7K的高大上(主要是VDC功能相当之高大上,喂,一台设备变N台还不牛逼?)N5K算是小跟班一个了,不论是使用三层构架还是坍塌的二层结构,N7K都是当之无愧的核心层设备,而N5K一般用在汇聚层,土豪点的用在接入层. 硬件上来说,区别于N7K的硬件模块化,N5K的硬件算是半模块化的(跟大多数中低端路由器很类似,有固定端口,又可以插小型的板卡用于扩展端口). 软件上来说,可以把N5K当成是N7K的一个VDC,跟N7

据说微软在爱荷华州启动了$ 1.1B的云数据中心

微软正在扩大在爱荷华州的数据中心运营.大型软件和云服务提供商已被确定为在西得梅因一块 154 英亩土地上的大型" Alluvion 项目"背后的公司.<strong>根据<四城市时报>的一份报告,该数据中心的成本预计将接近 11.3 亿美元.它将加入该地区先前宣布的" Project Mountain" ,这是微软耗资 7 亿美元的云数据中心,该中心于去年开绿灯.</strong> 该报告指出,微软在该地区的投资接近 20 亿美元

[运维] 第五篇:数据中心改善运维,ITIL与ISO20000如何选择?

企业数据中心需要改善运维现状,提高运维水平,更好的为业务服务,ITIL肯定是不二的选择,因为毕竟ITIL是运维方面的最佳实践.但是ITIL只是告诉你如何才能提高运维能力,但是并没有告诉你怎么才能在你的企业里做好ITIL的落地工作,进而真正对运维发挥效果,所以具体怎么做,还是得你按照ITIL的理念去结合企业实际情况去落地.落地的时候你可能会有两个选择,是通过ITIL流程落地呢?还是去通过ISO20000认证呢?          因为本文不是讲ITIL和ISO20000的帖子,所以具体的讲解可以通

鬼泣之家用数据中心

鬼泣之家用数据中心 VSAN(存储)+NSX(网络)+horizon(应用)+vrealize(监控)+veeam(备份)+ossim(侦听)+prtg(运维) 假设你家有一间客厅一间卧室,客厅和卧室都有一个小格子,客厅的格子里面你可以放cisco asa5506X+cisco 2960X,三台沙漠之鹰二(mini-itx,内置c236芯片组,i5,ddr4,ssd+hhd,双网卡), 而卧室也有一个小格子,里面放juniper srx 210he ,juniperex3200,三台沙漠之鹰二.

Java实验四和实验五

实验四 类的继承性和多态性 [开发语言及实现平台或实验环境] Windows2000 或XP,JDK1.6与Jcreator4.0 [实验目的] 1.  掌握OOP方式进行程序设计的方法, 2.  了解类的继承性和多态性的作用. [实验要求] 1.  编写体现类的继承性(成员变量,成员方法,成员变量隐藏)的程序. 2.  编写体现类多态性(成员方法重载,构造方法重载)的程序. [实验内容] 一 类的继承性练习 1. 进一步理解继承的含义 新类可从现有的类中产生,并保留现有类的成员变量和方法并可根

绿色数据中心节能,值得探究的八大秘密

随着企业信息化建设的迅速发展,数据中心建设越来越重要,将直接影响企业信息系统的建设和应用效果.根据IDC的估算,从运行成本控制的角度看,在IT行业中,能源消耗成本已经达到企业硬件采购成本的25%.而数据却正以52%的复合年均增长率不断攀升.当企业面对不断变化的业务压力,以及呈指数级快速增长的数据时,需要对数据中心环保.节能方面的特性予以足够的考虑和重视. 如何在确保数据高度安全和高度可靠的前提下,最大限度地保证企业在数据中心建设中能够减少浪费和降低无效投入,打造一个真正"绿色节能"的数