作者：Umberto Manferdini 译者：TF编译组

服务链的核心是服务实例。服务实例通过端口元组将链（chain）“链接”到虚拟机，而该虚拟机就是流量所经过的实际实例。

这个虚拟机也代表着单点故障！如果VM死亡，则其接口也将死亡，于是，端口元组将引用“死”的接口。结果是什么？流量的丢失！

保持服务链或服务实例的冗余，是很重要的。

要了解冗余是如何实现的，有必要回顾一下服务链路由的工作方式。

让我们考虑一下这个例子：

现在，我们在左右VN之间有一个网络策略。

TCP流量发送到服务实例“usa”，而UDP流量发送到服务实例“europe”。

在评估流（flow）时，与规则匹配的流量将发送到相应的“服务”VN。例如，TCP流量将发送到left_service_usa。在评估网络策略规则时，Tungsten Fabric不会考虑服务实例的状态。通过这种方式，Tungsten Fabric就不需要关心服务实例的端口元组所引用的接口状态。

因此，假设我们有一个TCP流，并且服务实例“usa”中端口元组引用的接口已关闭（down）。Tungsten Fabric将如何表现？流量与第一个规则匹配后，将发送到服务实例“usa”，也就是left_service_usa的VN。那里没有有效的下一跳，这导致了流量丢失。

现在，你应该清楚如何通过服务链来解决冗余问题了。冗余必须允许服务VN中有多个下一跳。

实现它的方法，是在服务实例中配置多个端口元组。

这就是链条的由来：

从左侧到右侧的所有流量，都通过服务实例“pippo”。

在该服务实例内，我们配置两个端口元组：一个引用vFW1端口，另一个引用vFW2端口。

结果如何？当路由从右侧向左侧泄漏时，两个端口元组的左侧接口都将设置为下一跳，从而导致通过ECMP下一跳，可以访问源自右侧VN的路由。

例如，右侧VN的路由为0/0。如果路由策略允许，该路由将泄漏到左侧VN。在泄漏时，Tungsten Fabric会检查服务实例的所有端口元组，获取所有剩余的接口，并将它们设置为下一跳。结果就是，从左侧VN的角度来看，0/0的ECMP下一跳具有两条相等的成本路径：一条通过vFW1，一条通过vFW2。

如果一个vFW死亡，我们还有另一个！这就实现了冗余！

从右侧到左侧的方向，也同样适用。

站在实际的角度来看，使链变得冗余，只需要我们简单地根据需要添加任意数量的端口元组：

默认情况下，这种冗余是active/active的。

在前面的示例中，基于哈希结果，新的流从左到右可以遍历vFW1或vFW2。考虑到我们提到了ECMP下一跳，这是显而易见的。

作为另一种方案，active/backup冗余也是可以实现的。

为了实现这一目标，我们必须回顾另一个Tungsten Fabric的概念。VMI（虚拟机接口）是路由元素，因为它们可以在其上配置本地优先级的值。该值可以由用户配置。

这里的想法是，在引用作为active的VNF的端口元组的vmis上保留默认值（LP = 200），而在引用作为backup的VNF的端口元组的vmis上设置更差的值（LP = 100）。

这样，所有下一跳是backup vFW接口的路由都将具有LP = 100的值。

让我们再次考虑0/0路由。一旦泄漏到左侧VN，我们将获得该路由的两个副本：一个通过LP = 200的vFW1，另一个通过LP = 100的vFW2。Tungsten Fabric将运行BGP最佳路径选择，当然，通过vFW1的路由将变为active状态。

与Junos相似，此路由将进入FIB（在本例中为vRouter的FIB）。同时，RIB中已经准备好通过vFW2的另一种路由，一旦发生故障，它将被加载到FIB中，从而帮助我们实现快速收敛！

当然，我们在这里讨论的所有功能仍然有效！通过策略控制泄漏，最重要的是，使用运行状况检查来快速检测故障，并最大程度地利用这种冗余！

细说TF服务链 ——

Tungsten Fabric 架构解析系列文章 ——

ITPub博客