大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全家桶1年46,售后保障稳定
这个实验有点长,看官慢慢看!
传说中用来取代生成树(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 | 无意义 |
转载于:https://blog.51cto.com/lu16520/1684753
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/227284.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...