要在数据中心实现快速收敛？你需要一个快速IP Fabric

先说一句看起来很“傻”，但在我看来并非琐碎的话：如果一切都按预期进行……那么一切就都会顺利进行。

想象一下这样的网络：你设置链接，配置路由协议，检查端点是否可达。在正常情况下，数据包会如愿以偿地流动，用户也会对自己的体验感到满意。

但是，如果网络内部出现故障怎么办？我们确实设置了路由协议来交换和传播路由信息，但这还不够。路由协议不一定要简单地提供端点之间的可到达性，它们必须被设计成能够高效地应对网络故障。

那么“高效”又是什么意思？如果我们是在学校里学习，“高效”的意思就是快，我们确实希望将流量损失降到最低，因为这会导致服务中断，同时我们还希望系统的算法能够快速从故障中恢复。如果我们是在公司工作，“高效”仍然意味着快，压力也会更大，服务中断就意味着“金钱的损失”……

总之，在这两种情况下，效率都意味着“快”。网络在处理故障的时候，必须要快。我们要尽可能地减少流量损失！

这就引出了网络设计的一个基本话题：收敛！

数据中心内部的收敛

自第一个网络部署以来，网络收敛一直是非常重要的一个方面。

当然，当你开始学习计算机网络时，一定听说过当一条链路故障时的生成树收敛，OSPF重新计算路径所需的时间，用于实现邻居关系的bgp保持计时器不再活跃等等。

所有这些考虑因素在创建网络时仍然存在，而且至关重要，现在，我们把它们带到了数据中心里面。

说到数据中心，我指的是IP Fabric，一个使用BGP作为路由协议的leaf和spine网络，并在leaf层限制L2功能（ERB模型）。有了这些假设，就不难理解很多“老”的快速收敛概念又回来了。

让我们来看一个示例拓扑：

我们有一个2×2的IP Fabric（2个leaves，2个spines），一个DC网关连接到两个spine（在真实的网络中，我们很可能有冗余的DC网关）。

我们有服务器连接到leaves上，这些服务器是多归属连接到Fabric上的（绑定接口，每个leaf上都有一个成员连接）。

来看看收敛是在哪里成为对话的一部分。

在服务器和leaf之间，我们有一个LAG，因此，收敛主要是在一个成员故障的情况下，绑定失败的速度。在这里，我们期望亚秒级的故障切换时间，或者最坏的场景下，我们依靠LACP定时器（如果使用快速速率，那么我们期望检测时间为3×1秒）。

而在IP Fabric内部，事情变得更加复杂……

VTEPS的可达性取决于底层BGP。这里的收敛，是指BGP收敛。由于直接连接的接口地址之间使用的是eBGP，所以故障转移应该是非常快的。Hold Time不应该出现（除非软件层面的问题）；BFD也可以做类似的考虑。

接下来，对于EVPN驱动的连接，fabric ibgp overlay就变得相关了。在这里，由于在环回地址之间建立了BGP，来自BFD的帮助就成为关键。

现在，让我来预测一下这个讨论的关键论点吧。2个leaf节点之间有多条路径；这来自于leaf & spine架构在两个leaf节点之间提供的多条ecmp路径。想象一下，从leaf1到leaf2的overlay ibgp数据包穿越spine1。如果leaf1-spine1的链接失效，并不意味着两个leaf不能再连通；它们可以通过spine2的备用路径。

因此，overlay ibgp bfd定时器的速度不能快于underlay适应故障并提供leaf1和leaf2之间的备用路径所需的时间。由于underlay依赖于直连的接口地址之间配置的eBGP，反应时间应该非常快，因此我们可以设置非常低的BFD定时器。

此外，由于设备上启用了ecmp，当一条链路发生故障时，leaf和spine已经将替代路径加载到FIB（包转发引擎表）中；这进一步将收敛时间降到最低，因为我们消除了将替代路由从RIB加载到FIB所需的时间（虽然很短，但它仍然存在）。

这给了我们什么启示呢？

如果系统A的收敛时间为X，而系统B使用系统A作为传输层，那么系统B的收敛时间不可能比X更快！

这在后面会很方便。

出于关闭fabric收敛的考虑，当一个ESI成员失败时，必须发送type 1 withdraw路由，以便让其它leaf知道有些MAC不能再通过发起这些type 1路由的leaf到达。某种程度上，这与ibgp overlay收敛有关。

最后我们要涉及的部分是DCGW和和spine之间的路径。在这里，我假设了一个设计，有单独的p2p链路连接DCGW和spine（没有ESI LAG），并且eBGP会话通过直