这个实验有点长，看官慢慢看！
传说中用来取代生成树（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
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/227284.html原文链接：https://javaforall.cn
