Tungsten Fabric如何实现路由的快速收敛？收敛速度有多快？

在发布R2008版本之前，Tungsten Fabric无法同时提供南北向和东西向流量的快速收敛。
实际上，对于南北流量来说，是可以实现快速收敛的，但机制在Tungsten Fabric的逻辑之外：

一个解决方案是将overlay的control_node-sdn_gw的BGP会话分成两个会话，以解决在Tungsten
Fabric上缺乏BFD的问题（但这个问题无法完全解决）。包括一个iBGP会话，不含BGP，在Tungsten Fabric和IP
Fabric spine之间；一个eBGP会话，含BFD，在spine和SDN
GW之间。在这些会话中，交换了overlay路由。因此，一旦eBGP下线，所有指向SDN
GW的overlay路由都会从spine上被移除，而spine也会告诉TF控制节点移除这些路由。
另一个解决方案是在SDN网关上实现下一跳可达性检查，这样MPLSoUDP只有在计算节点还活跃/可达的情况下才会启动。如何实现？我们稍后再谈。

两种变通的方法都能为我们提供南北向的快速收敛。无论如何，东西向的流量仍然容易出现收敛缓慢的情况，因为它依靠的是XMPP timer（默认情况下非常缓慢）。

实现原理：下一跳的可达性

为了带来快速收敛，Tungsten Fabric在概念上实现了我们刚才提到的SDN网关的解决方案：下一跳的可达性。

背后的思路，就是利用过去已经使用过的相同构件来验证SDN GW计算节点是否活跃。

下图是总结的解决方案：

假设IP Fabric实现的是ERB模式（在VMTO的帮助下，CRB模式也是可以的），ERB是指叶子节点为L2/L3 GW，简单地说，就是在叶子节点上配置了VLAN IRB接口。

在这种模式下，一旦叶子节点学习到一个MAC:IP对，它就会为该IP在inet.0中安装一个/32路由，其下一跳是该IP所属VLAN的IRB逻辑接口。

在我的测试拓扑中，2个计算节点连接到leaf2。结果如下：

它们在这里了！每个连接的服务器都有一条/32路由！

现在，我们要通过underlay会话向spine通告这些路由：

策略导出本地环回（因为是vtep地址，所以需要有）和那些协议evpn路由。

于是，现在所有计算节点的spine都有了一条/32路由。

如果其中一个计算节点发生故障，或者连接叶子节点和服务器的链路（或多服务器的链路）发生故障，那么/32路由将从叶子节点上消失。结果就是，将向spine发送一个BGP UPDATE，通知“删除该/32路由”。

Spine也会收到SDN GW的环回地址。我们希望这个SDN GW环回是南北向流量的MPLSoUDP隧道端点。

现在，在Tungsten Fabric中实现快速收敛的解决方案应该很清楚了。基本的概念是：指向计算节点的/32路由的存在被解释为计算活跃的标志；当我们看到这个路由，那么计算节点就已经启动并运行了；如果给定的计算节点没有/32路由，那么这个计算节点应该被标记为死机，没有流量将被转发到它那里。这就是我们说的下一跳的可达性。

我们需要的做最后一步，是将这些/32路由带到TF。这可以通过在控制节点和spine之间的会话上配置family inet来实现。这将允许spine向TF发布/32 evpn路由通告。

Tungsten Fabric会将这些路由存储到inet.0表中。现在，是解决方案的核心部分。假设compute1死机。相应的/32将作为BGP withdraw消息的结果从inet.0中移除。该下一跳将不再可到达，任何通过它到达的路由都将无法通过下一跳可达性测试。因此，该下一跳后面的所有overlay路由都将失效。

当然，这里有个假设是，所有这些步骤都是在很短的时间间隔内发生的，比长的XMPP timer要短得多。后面我们将会看到这有多快！

如果故障节点是SDN GW，也会出现同样的情况；记住，spine同时向服务器/32路由和SDN GW环回发布通告！

当然，一旦控制节点删除了所有的路由，它也会通知它的对等体（peer）：SDN GW通过BGP，计算节点通过XMPP。

这就是快速收敛的原理。正如你所看到的，它并非“仅仅是Tungsten Fabric”，而是不同角色的组合：

叶子节点必须快速检测到服务器不再可达，从而删除/32路由。
fabric必须快速地将这些信息通过BGP传播到TF节点。
控制节点必须快速更新其路由表，并向SDN GW和计算节点传播信息。
计算节点必须快速更新其转发表。

启用Nh可达性检查

在查看这个收敛有多快之前，我们先来看看它是如何配置的。如前所述，这个功能从R2008版本就有了。

在配置模式中，我们在全局设置下找到快速收敛设置：

同时启用“Nh可达性检查”和“启用”两个复选框。此外，我们还可以配置XMPP timer，以使用比默认选项更小的timer。

如果我们有了nh可达性检查，为什么还需要XMPP保持定时？这里，nh可达性检查是为了解决网络故障，即叶子节点能够检测到连接到服务器的问题的故障。但这并不是我们可能遇到的唯一的故障。叶子节点和服务器之间的链路可能是可以运行的，但是vRouter软件出现了问题，没有正确处理数据包。在这种情况下，叶子节点不会删除/32路由，控制节点也不会因为nh可达性检查失败而导致路由无效。如果是这样，我们就需要依靠XMPP保持到期时间，让控制节点意识到计算节点已经死机。

在这里，我们重点介绍基于nh可达性检查的快速收敛。

启用快速收敛是不够的。我们需要在控制节点和spine之间的BGP会话上增加family inet unicast：

有一个细节我们需要知道。我们必须在spine BGP路由对象（1.1.1.1）和控制节点 BGP路由对象（192.168.200.10）上添加 family inet。如果其中一个对象上缺少inet，family inet就不会被TF control通告。

让我们检查一下发送这些路由的spine：

Spine正在通告计算节点地址和SDN GW环回地址（2.2.2.1）。它还通告控制节点的IP地址（由控制节点连接的叶子节点也会为该地址生成一个/32）。

Tungsten Fabric将这些路由存储到inet.0中：

前面说过，在检查下一跳可达性时，控制节点会验证该下一跳是否作为inet.0中的一个条目。

收敛速度到底有多快

现在，是时候验证一下收敛的速度了。

我的集群是TF+K8s集群。如你所见，有两个计算节点。

每个计算节点都运行一个连接到默认pod网络的pod：

我打算将compute2从fabric中隔离出来。

我们可以期待看到什么？

控制节点删除指向192.168.200.12（compute2节点）的inet路由和该计算节点后面的所有overlay路由
将该信息传播给compute1节点

为了隔离节点，我禁用了连接叶子节点和服务器的接口。

提交（commit）发生在：

0   2020-11-24 08:57:40 PST by root via cli

我们检查叶子节点上的BGP轨迹，看看什么时候发送BGP更新：

在控制节点上，我们使用Introspect Sandesh Trace来查看BGP更新何时到达：

接下来，我们使用tcpdump查看控制节点何时向compute1（192.168.200.11）发送XMPP更新：

我们还可以用Wireshark可视化XMPP数据包，看它们说要“删除192.168.200.12”：

最后，在compute1上，我们再次使用Introspect Sandesh Trace来查看路由是何时从转发表中删除的。
vRouter将compute2前缀删除：

同时删除的还有pod前缀：

每个前缀有3个条目，这些路由可以在3个虚拟网络中找到。

我们将时间戳转换并得到：

让我们来总结一下所有的部分：

总的来说，我们花了2.5秒的时间来实现收敛（假设在08:57:40.000提交，这是最坏的情况）。总之，这里的大部分时间，2秒，是从提交到BGP更新发送之间的时间。

这个时间间隔的意义不大。为什么这么说呢？有下面几个原因。

第一，这样的故障是人为的，包括提交时间。第二，我在虚拟环境中使用了vMX，所以不是在测试真实的故障情况。第三，由于前面的考虑，我们没有一个精确的故障检测时间值，也就是设备意识到服务器已经无法到达并删除/32路由所需要的时间。而且即使我们有，那也是虚拟MX所需要的时间，在现实情况中，我们很可能会有一个物理QFX。

因此，最好关注从发送BGP更新到计算节点删除路由的时间。这个时间间隔大约是450毫秒，是一个很好的数值。

综上所述，收敛时间可能在450毫秒左右+叶子节点检测时间，正如我们所说，必须在真实环境中验证。只要这个检测时间在500ms左右，就可以说我们实现了亚秒级的收敛！