数据中心分解实验（五）-abricPath

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新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
DC2-N5K-1	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算法计算后做负载均衡。