uplinkfast-CSDN博客

UplinkFast工作原理

1,背景知识

下图是一个典型的冗余网络的设计。用户设备连接到接入交换机，接入交换机用两条链路分别接到两个核心交换机上。由于冗余网络中存在环路，那就需要STP来阻塞某些端口。

当接入交换机连接到D1的链路失效（down）时，STP就会重新计算，最终会把通往D2的链路设置为forwarding，那这样就会使得网络继续通畅。但是以STP默认参数来计算的话，整个网络恢复通畅需要30秒钟。如果使能了aggressive timer tuning，这个时间可以减少到14秒。如果使用了uplinkfast，那这个恢复时间可以减少到1秒。

2,没有使能uplinkfast的上行链路失效

本节以上节中拓扑为例，讲解当上行链路失效时STP的行为。每一个步骤都有一个图来演示。

D1和D2是两个核心交换机。D1被配置为网络的根桥。A是一个接入交换机，它的某一个上行口是blocking状态。

1.假设A和D1之间的上行链路断开

2.P1断开立刻进入down的状态，交换机A就感知其到D1的上行链路断开。交换机A的P2端口是alternate端口，并且它仍然在接受BPDU报文。交换机A可以把P2端口从blocking状态转移到forwarding状态。为了实现这个过程，它必选要经历listening，learning状态，每一个状态都需要一个forward_delay（默认是15秒）的时间，那就要把P2端口再阻塞30s，之后它才能进入forwarding状态。

3. 一旦P2进入了forwarding状态，对于连接到A上面的主机来说，网络就重新畅通了。但是网络中断了30s。

3,Uplink Fast的运行理论

UplinkFast是一个基于上行链路组(uplink group)的概念。对于一个给定的交换机，上行链路组包含根端口(root port)和所有alternate端口。如果根端口down了，上行链路组中下一个最小代价的端口就立刻被选择为根端口(不需要经历listening，learning状态)

下图解释了uplinkfast所基于的理论：

图中，根端口用蓝色R表示，指定端口用绿色d表示。绿色的剪头表示根桥生成的BPDU报文被各个交换机在各自的指定端口上重新分发的方向。如果没有之前的所说的链路变化，那图中的BPDU和端口的状态都会处于稳定的状态：

当一个端口能够接收到BPDU报文，那这个端口必然有一条能够到达根桥的通路。这是因为BPDU报文是从根桥产生的。图中A交换机，一共有3个端口能够接收到BPDU报文，那它共有3条通路能够到达跟桥。A中发送BPDU报文的端口是指定端口，这个端口不会连接到根桥。
在任一个交换机上，除了根端口，那些能够接收到BPDU报文的端口都是blocking端口。能够接收到BPDU报文的端口都能连接到根桥。如果一台交换机有两个端口都能连接到根桥，那就会有环路产生。
那些和自己交换机连接的端口，不会作为一个能够连接到根桥替换口。如图中B交换机，自我连接的端口被设置为block状态，那也就是说交换机不能接受自己产生的BPDU报文。在这种情况下，被阻塞的端口不会提供一条到根桥的替换通路。

在一个给定的桥上，根端口和那些不是因为自我相环的被阻塞的端口就构成了一个上行链路组（uplink group）。这章节将逐步的讲解uplinkfast是如何利用上行链路中的替换口来实现快速的聚合。

注意：Uplinkfast只能在拥有bloacking端口的交换机上使能。这个功能是为那些接入交换机拥有冗余的上行链路拓扑而设计的。uplinkfast是对整个交换使能的，它不能再某一个vlan中使能。

4,使能uplinkfast时候的上行链路失效

本节将详细介绍uplinkfast的工作过程。使用本文开始时使用的拓扑来讲解。

4.1.立即却换到替换上行链路

切换到替换上行链路的完整步骤：

1.交换机A的上行链路组中含有P1和非自环的端口P2.

2.当D1和A之间的链路失效时，A检测到连接到P1端口的链路断开。

它立马就知道它通往根桥的的唯一通路失效了，那在上行链路组中的其他端口，例如P2就会被连通（unblock）。

3.将P2端口立刻设置为forwarding状态，这个违背了标准的STP处理流程。

因为通往根桥的唯一路径断了，那么网络中久没有环路了，因此，恢复是非常快的。

4.2.CAM(FDB)表的更新

一旦UplinkFast使得两条上行链路快速的切换，网络中交换机的CAM表中在某段时间内可能是无效的，并且还会使得网络流量的汇聚减慢。

为了阐述这个问题，在拓扑中我们增加了两个客户机（host），S和C：

每个交换机的CAM表如上图中所示。可见S如果要去C的话，报文必须要经过D2，D1，然后是A。

如下图所示，备份链路被连通：

备份链路很快地就被连通，然而CAM表将不在准确。如果S发送一个报文到C，那这个报文就会被转发到D1，到D1后，这个报文就会被丢弃。那S和C之间的通信因为CAM表的不正确而被中断了。即使有topology change机制，但是那也要等到15s才能恢复流量。

为了解决这个问题，交换机开始泛洪含将所有自身所学习到的CAM作为源MAC的空报文。这样，一个用C作为源MAC的报文在A中形成了，这个报文的目的MAC是CISCO的专有组播MAC，这个MAC能够确保这个报文在整个网络内能够被泛洪，并且能够用来更新其他交换机中的CAB表项。

这个空的组播报文的发送速率是可配置的。

4.3.新的上行链路的添加

当组上行链路失效时，在行链路组中，用来替代失效的主端口会被很快的选出。那当一个新的上行链路被连通，并且这个上行链路按照STP的运算应该成为新的主链路，那会怎么办呢？一个例子就是原来A上的根端口P1断开之后，端口P2取而代之成为根端口，但是一会A上P1端口又连通了。端口P1理所当然的回重新成为根端口的角色。那UplinkFast是否立刻允许P1很快的取代P2，并且把P2设位置blocking的状态呢？