细说TF服务链丨服务链后台的路由实现



  • 作者: Umberto Manferdini 译者:TF编译组

    上一篇文章中,我配置了最简单的服务链。现在,是时候了解路由实际上是如何实现的了。

    我们的拓扑结构是这样一条简单的服务链:
    1d00b938-0d6f-4a89-90bf-f238551e6f25-image.png

    让我们看一下路由表。

    从“分离的”VN开始:没有策略,没有服务链。

    7a24f86c-1e58-4648-82c2-71555ead7b07-image.png

    在本实例中,路由表仅包含该虚拟网络的地址。

    c323e957-69cd-46dc-93af-8643f06d546f-image.png

    接下来,应用策略,但不添加任何服务实例:

    171e0fc2-8f69-4173-8c46-3d635ac40ab6-image.png

    现在,左侧网络还包括来自右侧网络的路由:

    d8392e22-b888-45b2-b3f5-5645962297b1-image.png

    在这背后是什么?Route Target!

    为了解更多信息,我将在控制节点上使用Introspect并浏览路由表(模块为bgp_peer,然后使用ShowRoute family请求)。

    创建虚拟网络后,会自动为其分配Route Target。即使没有配置Route Target,仍然有一个VN。这种Route Target的值高于800万,因此很容易识别。

    指定左侧VN为target:64520:8000059
    86e41acc-cef6-46b9-b3a9-769b1928009a-image.png

    指定右侧VN为target:64520:8000060

    63644d36-8c2c-4e85-986f-c437b50a6cc0-image.png
    一旦我们应用网络策略,允许这两个VN之间进行通信,Tungsten Fabric就会自动调整导入Route Target策略。

    左侧VN现在会导入“8000060”,这意味着它将导入右侧VN的路由:
    bd8360b3-ae94-4e0a-9380-ba48d763687e-image.png

    右侧VN的更新方式类似,不过它将导入RT“8000059”,即左侧VN RT:

    8af258de-6891-4626-aa87-4b7e4253864d-image.png

    到最后,网络策略看起来似乎只是利用Route Target执行泄漏。

    那么,为什么在创建虚拟网络时,我们要花时间在网络策略上,而不仅仅是配置适当的Route Target,然后导入Route Target策略就好了?

    我们知道,网络策略允许创建L4规则。通过网络策略,可以决定允许TCP通信,以及阻止UDP通信。这就是重点,我们可以创建服务链。

    开始吧!最后一步,服务链:

    636eef0b-d51f-4123-a23f-b2bb9846e532-image.png

    查看左侧VN导入Route Target政策:
    267b31ea-fc06-4be9-ab5b-cd1d269f1109-image.png

    这很有趣……我们知道还有两个虚拟网络:
    –左侧,原始VN出来
    –左侧服务,一个辅助VN“映射”到了服务实例

    左侧VN导出RT“8000059”,而左侧服务则导出RT“8000061”。这两个VN相互导入RT。这意味着它们之间有泄漏!

    来看一下右侧的情况:

    3fa50172-203c-42fb-9248-9123079d911d-image.png

    我们看到了类似的东西:右侧和右侧服务相互导入RT。

    没有服务实例,左侧VN将导入右侧VN,反之亦然。现在,此机制仅限于左侧和左侧服务(或右侧和右侧服务)。那么,从右到左的路由如何到达?

    看起来,RT泄漏并不简单。

    在这种情况下,我们必须谈论路由重新分配。这意味着Tungsten Fabric将重新分配路由。仔细考虑一下,这是有道理的。

    假如没有服务实例,可以按原样从右向左复制路由,反之亦然。

    另一方面,在服务实例起作用的情况下,当一条路由从右侧“泄露”到左侧时,下一跳必须更新,因为它必须指向服务实例vmi。

    那么这是如何工作的呢?让我们看看右侧VN路由:192.168.20.3/32。

    跟以往一样,该路由有两个副本:XMPP和BGP。
    fab29502-852e-4b3f-a57b-4f9235fd1fd2-image.png

    查看这些路由更多的详细信息:
    fd259ac8-b82e-4b15-94ca-1b5474787b7e-image.png

    这里要注意的是,该路由具有一个辅助表,是的,它是右侧服务!这里右侧到右侧服务的泄露,是由于我们之前看到的导入Route Target策略。可以看到,BGP路由(第二个)导出RT“8000060”,而该RT是由右侧服务导入的。

    现在,我们转到左侧服务路由表:

    28a9f44a-cdd4-4d26-8fdf-ff1bad88abb0-image.png

    仍然有两条路由,但XMPP的那一条已被服务链的那一条所取代。

    此路由将左侧VN作为辅助表:

    baad5ee8-45dc-4e6e-b133-94b01f42b0d1-image.png

    下图表示了路由的传播:

    4cc02bc7-0698-4d18-bd84-19b1733a8419-image.png

    当流量从左向右移动时,会发生以下情况:

    c3b52ccd-74f5-4751-b6f6-3550d326626d-image.png

    回程流量利用了现有流量。

    是不是有点复杂?可能是的……但是考虑一下,我们为创建这条链实际配置了什么,很明显Tungsten Fabric是如何隐藏了所有的复杂性!

    下一次,我将开始研究高级服务实例的设置。


    细说TF服务链

    一文讲透什么是服务链(多图)
    手把手教你配置服务链


Log in to reply