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计算节点是否活跃。

    下图是总结的解决方案:
    960d5810-a56b-45f1-893a-a87712506b00-image.png
    假设IP Fabric实现的是ERB模式(在VMTO的帮助下,CRB模式也是可以的),ERB是指叶子节点为L2/L3 GW,简单地说,就是在叶子节点上配置了VLAN IRB接口。

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

    在我的测试拓扑中,2个计算节点连接到leaf2。结果如下:
    62e73672-3cdd-4624-b770-815faeabf76a-image.png
    它们在这里了!每个连接的服务器都有一条/32路由!

    现在,我们要通过underlay会话向spine通告这些路由:
    67ce575a-53a2-4d59-a87e-e20a7a34d07b-image.png
    策略导出本地环回(因为是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版本就有了。

    在配置模式中,我们在全局设置下找到快速收敛设置:
    10ce3002-6b13-4632-a788-8694e1b5891d-image.png
    同时启用“Nh可达性检查”和“启用”两个复选框。此外,我们还可以配置XMPP timer,以使用比默认选项更小的timer。
    如果我们有了nh可达性检查,为什么还需要XMPP保持定时?这里,nh可达性检查是为了解决网络故障,即叶子节点能够检测到连接到服务器的问题的故障。但这并不是我们可能遇到的唯一的故障。叶子节点和服务器之间的链路可能是可以运行的,但是vRouter软件出现了问题,没有正确处理数据包。在这种情况下,叶子节点不会删除/32路由,控制节点也不会因为nh可达性检查失败而导致路由无效。如果是这样,我们就需要依靠XMPP保持到期时间,让控制节点意识到计算节点已经死机。

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

    启用快速收敛是不够的。我们需要在控制节点和spine之间的BGP会话上增加family inet unicast:
    33f2a143-2fe1-4540-9903-49bfd0afef1b-image.png
    有一个细节我们需要知道。我们必须在spine BGP路由对象(1.1.1.1)和控制节点 BGP路由对象(192.168.200.10)上添加 family inet。如果其中一个对象上缺少inet,family inet就不会被TF control通告。

    让我们检查一下发送这些路由的spine:
    8d27b203-07e5-4a3a-878d-b184ebb6091b-image.png
    Spine正在通告计算节点地址和SDN GW环回地址(2.2.2.1)。它还通告控制节点的IP地址(由控制节点连接的叶子节点也会为该地址生成一个/32)。

    Tungsten Fabric将这些路由存储到inet.0中:
    8b4db014-39e6-4829-a50f-4c1303385c44-image.png
    前面说过,在检查下一跳可达性时,控制节点会验证该下一跳是否作为inet.0中的一个条目。

    收敛速度到底有多快

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

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

    每个计算节点都运行一个连接到默认pod网络的pod:
    b85fce65-2a1d-45f3-ab57-152a29b750c6-image.png
    我打算将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更新:
    8aecf6c5-7e18-460d-a0b3-8e59876e08e7-image.png
    在控制节点上,我们使用Introspect Sandesh Trace来查看BGP更新何时到达:
    131f8d74-89bc-4157-b6a1-3d31a5b05399-image.png
    接下来,我们使用tcpdump查看控制节点何时向compute1(192.168.200.11)发送XMPP更新:
    34237fd9-e32c-4f88-93a7-f3fdbeb73ca9-image.png
    我们还可以用Wireshark可视化XMPP数据包,看它们说要“删除192.168.200.12”:
    013334b9-7b76-4c1d-a481-06736900ed0e-image.png
    最后,在compute1上,我们再次使用Introspect Sandesh Trace来查看路由是何时从转发表中删除的。

    vRouter将compute2前缀删除:
    3a008493-2178-44ce-aeea-3bdd2d48435f-image.png
    同时删除的还有pod前缀:
    c9264383-a340-4269-ae9a-bb2dae8c09e5-image.png
    每个前缀有3个条目,这些路由可以在3个虚拟网络中找到。

    我们将时间戳转换并得到:
    5f531976-0434-472a-bc23-6cfe548787bf-image.png
    让我们来总结一下所有的部分:
    586550be-4b7d-42cc-b140-333112d618cb-image.png
    总的来说,我们花了2.5秒的时间来实现收敛(假设在08:57:40.000提交,这是最坏的情况)。总之,这里的大部分时间,2秒,是从提交到BGP更新发送之间的时间。

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

    第一,这样的故障是人为的,包括提交时间。第二,我在虚拟环境中使用了vMX,所以不是在测试真实的故障情况。第三,由于前面的考虑,我们没有一个精确的故障检测时间值,也就是设备意识到服务器已经无法到达并删除/32路由所需要的时间。而且即使我们有,那也是虚拟MX所需要的时间,在现实情况中,我们很可能会有一个物理QFX。
    因此,最好关注从发送BGP更新到计算节点删除路由的时间。这个时间间隔大约是450毫秒,是一个很好的数值。
    综上所述,收敛时间可能在450毫秒左右+叶子节点检测时间,正如我们所说,必须在真实环境中验证。只要这个检测时间在500ms左右,就可以说我们实现了亚秒级的收敛!


    作者:Umberto Manferdini 译者:TF编译组
    原文链接:https://iosonounrouter.wordpress.com/2020/11/26/how-contrail-fast-convergence-works-and-how-fast-it-can-be/



Log in to reply