先说一句看起来很“傻”，但在我看来并非琐碎的话：如果一切都按预期进行……那么一切就都会顺利进行。
想象一下这样的网络：你设置链接，配置路由协议，检查端点是否可达。在正常情况下，数据包会如愿以偿地流动，用户也会对自己的体验感到满意。
但是，如果网络内部出现故障怎么办？我们确实设置了路由协议来交换和传播路由信息，但这还不够。路由协议不一定要简单地提供端点之间的可到达性，它们必须被设计成能够高效地应对网络故障。
那么“高效”又是什么意思？如果我们是在学校里学习，“高效”的意思就是快，我们确实希望将流量损失降到最低，因为这会导致服务中断，同时我们还希望系统的算法能够快速从故障中恢复。如果我们是在公司工作，“高效”仍然意味着快，压力也会更大，服务中断就意味着“金钱的损失”……
总之，在这两种情况下，效率都意味着“快”。网络在处理故障的时候，必须要快。我们要尽可能地减少流量损失！
这就引出了网络设计的一个基本话题：收敛！
数据中心内部的收敛
自第一个网络部署以来，网络收敛一直是非常重要的一个方面。
当然，当你开始学习计算机网络时，一定听说过当一条链路故障时的生成树收敛，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会话通过直连的接口地址建立。在这种情况下，为Fabric eBGP underlay所做的考虑仍然有效，因为我们使用相同的动态路由协议。
这涵盖了数据中心内部不同的收敛方面。
南北流量路径收敛场景
现在，让我们看看当需要在南北流量路径上进行收敛时会发生什么。
考虑一下下面这个场景：
我们有一个双归属到两个Leaf节点的VNF虚拟路由器 由于某些原因必须与DCGW对话。这条路径代表了南北流量的一个典型例子。
现在，想象一下这两个端点通过BGP会话交换路由信息的情形。
虚拟路由器可能充当DC内部运行的虚拟机的虚拟路由反射器。如果你仔细想想，这种用例并不是虚幻的。设置一个虚拟的RR是有意义的；你可能会通过依靠IP Fabric路由来实现类似的东西，但是很可能的是，你不希望在leaf（或spine）RIB里面带来太多的路由。
此外，如果考虑到Contrail，Contrail Controller节点将作为路由反射器，并且与DCGW交换路由信息。
在BGP会话的基础上，我们还配置了BFD，以便有更快的故障检测能力。
现在，最大的问题是……如何设置BFD定时器？
让我们看看，在正常情况下，BGP和BFD包可能流向哪里：
有四条可能的路径。第一次裂变发生在VNF层，取决于哈希函数的计算来选择一个LAG成员。第二次裂变发生在leaf上，因为DCGW可以通过2条ecmp路径到达。当然，属于同一个流的数据包（相同的5-tuple）将采取相同的路径，因为哈希函数给所有数据包的结果是相同的。
可能发生的故障推演
现在，我们来看看可能的故障。
一个LAG成员可能会发生故障：
如前所述，在这里，收敛时间取决于LAG的反应；假设需要X时间才能收敛。
另一种可能发生的故障是leaf-spine故障：
在这种情况下，收敛时间取决于underlay BGP（记住，我们是在ERB模型中，所以evpn对端到端路径没有影响）。假设需要Y时间才能收敛。
回到我们的BFD定时器问题。在这两种故障场景下，BGP端点（虚拟路由器和DCGW）仍然可以通过替代路径到达对方。重要的是，我们必须允许fabric在端到端BGP会话下线之前提供该替代路径。这意味着BFD故障检测时间必须至少是max(X,Y)。
这告诉我们在谈论数据中心的收敛时一些最基本的东西：每次我们“围绕IP Fabric设计收敛”的时候，都依赖于IP Fabric的收敛时间。
这对现代架构有很大影响。想一想vEPG的用例：整个移动链将依赖于Fabric收敛。对于任何在数据中心内运行的应用来说，Fabric的恢复速度越快越好。
虚拟环境下的收敛案例
让我们简单看一下我们描述的一个例子。
我在一个虚拟环境中构建了之前展示的拓扑结构。由于是虚拟环境，设备之间并不是通过真实的线缆连接，而是通过中间的虚拟交换机进行连接。
这就意味着，如果S2接口发生故障，S1接口不会宕机，因为S1-vswitch的链路还在。
这是我的虚拟实验室环境的一个限制条件。
这主要意味着两点。第一，如果leaf上的LAG成员被禁用，虚拟路由器会在LACP检测到故障后发现这一情况。第二，fabric BGP underlay必须依赖hold timer。由于这个定时器太长，我把BFD也配置在这些会话上。
其实，这些虚拟环境给出的限制对我们的目的来说并不坏。由于我们不得不处理以秒为单位的收敛时间，因此将更容易观察到我们感兴趣的事件。
在fabric内部，我为BGP underlay配置了以下BFD定时器：
代码语言：javascript复制set groups bf_underlay protocols bgp group underlay bfd-liveness-detection minimum-interval 1000
set groups bf_underlay protocols bgp group underlay bfd-liveness-detection multiplier 5定时器很大，正如所说，这是选择出来的。
在虚拟路由器上，我们做如下设置：
代码语言：javascript复制set protocols bgp group dcgw bfd-liveness-detection minimum-interval 300
set protocols bgp group dcgw bfd-liveness-detection multiplier 3这些是端到端（虚拟路由器-DCGW）BGP会话的BFD定时器。
我们有大约1秒与5秒两种情况。
此时，我们禁用BGP和BFD数据包流动的leaf spine链路。
大约1秒后，在虚拟路由器上，由于BFD会话关闭，BGP会话被关闭：
代码语言：javascript复制Feb 12 02:14:55 bms bfdd[6205]: BFD Session 1.1.1.1 (IFL 0) state Up -> Down LD/RD(16/17) Up time:00:02:09 Local diag: NbrSignal Remote diag: CtlExpire Reason: Received DOWN from PEER.
Feb 12 02:14:55 bms bfdd[6205]: BFDD_TRAP_MHOP_STATE_DOWN: local discriminator: 16, new state: down, peer addr: 1.1.1.1无论如何，虚拟路由器和DCGW仍然可以通过fabric提供的替代路径相连通，我们只需要等待fabric收敛。
4秒之后发生了什么：
代码语言：javascript复制Feb 12 02:14:59 leaf2 bfdd[1739]: BFDD_STATE_UP_TO_DOWN: BFD Session 192.168.3.1 (IFL 567) state Up -> Down LD/RD(16/17) Up time:00:05:02 Local diag: CtlExpire Remote diag: None Reason: Detect Timer Expiry.
Feb 12 02:14:59 leaf2 rpd[1728]: bgp_bfd_callback:187: NOTIFICATION sent to 192.168.3.1 (External AS 65511): code 6 (Cease) subcode 9 (Hard Reset), Reason: BFD Session Down
Feb 12 02:14:59 leaf2 bfdd[1739]: BFDD_TRAP_SHOP_STATE_DOWN: local discriminator: 16, new state: down, interface: xe-0/0/0.0, peer addr: 192.168.3.1这4秒钟来自于两个BFD会话上配置的检测时间的差异。
接下来会发生什么？Fabric收敛，端到端BGP会话（虚拟路由器到DCGW）又出现了。结果呢？我们导致了BGP会话flap！
为了避免这种情况，我们需要在端到端会话上增加BFD定时器的时间；例如增加到3×2.5秒：
代码语言：javascript复制set protocols bgp group dcgw bfd-liveness-detection minimum-interval 2500
set protocols bgp group dcgw bfd-liveness-detection multiplier 3在这种情况下，我们给fabric必要的时间来收敛，避免不必要的flapping（考虑到当DCGW将这些路由发送到其它地方，flapping的影响可能会扩展到其它设备，将导致整个网络的不稳定）。
如果将BGP underlay BFD检测时间降低到2秒呢？在这种情况下，LAG故障切换（LACP 3秒）将成为约束条件，也就是说端到端BFD检测时间应该高于3秒。
这完美的说明了在数据中心环境中运行的服务，其快速收敛的处理离不开fabric的收敛。
那么，我的虚拟化服务能快速收敛吗？是的……但可能不会比你的IP Fabric更快！
原文链接：https://iosonounrouter.wordpress.com/2020/02/13/to-have-fast-convergence-inside-a-dc-you-need-a-fast-ip-fabric/
作者：Umberto Manferdini 译者：TF编译组
