细说TF服务链丨如何配置服务链的高级功能

Posted 2020-12-18

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

在之前的文章中，我谈到了什么是服务链，以及如何配置基本的服务链。让我们回顾一下服务链的构建方式：

• 一个网络策略（在两个虚拟网络之间应用，例如左侧VN和右侧VN）
• 一个服务实例（已配置好该网络策略）
• 包含了端口元组（仅是VMI引用列表）的服务实例
• 在这种情况下，服务实例具有两个定义的接口（左和右），这意味着端口元组将具有两个元素
• 端口元组引用在OpenStack上运行的现有VM的2个VMI
• 在左右VN之间移动的流量将通过该防火墙VM

在定义服务实例对象时，可以配置高级功能。这些高级功能在服务实例对象中进行配置。

我们展示了网络策略如何导致相关虚拟网络之间的路由泄漏。在这种情况下，右侧VN路由将泄漏到左侧VN中，此时将服务实例左侧接口用作下一跳，反之亦然（右侧VN中的左侧VN路由，会将服务实例右侧接口用作下一跳）。

可以通过配置路由策略来控制此泄漏。路由策略使用Junos语法，因此，如果有Junos经验，编写这些策略就会很容易！

例如，该策略接受0/0路由，并拒绝其它任何内容（路由更新）！

通过将策略映射到服务实例对象定义内的左/右接口来应用策略：

虚拟机可以使用BGPaaS宣布/接收来自Tungsten Fabric的路由。如果虚拟机不支持BGP，则可以在VMI上定义静态路由：

首先，我们定义静态路由：

应用于VMI的静态路由定义为“接口路由表”。如您所见，这些路由没有配置下一跳。下一跳将自动设置为应用了静态路由的VMI。

在一个服务链中，当定义服务实例对象时，静态路由会应用在接口级别：

结果是，左侧VN的路由为0/0，下一跳为服务实例左侧接口，而右侧VN的路由为192.168.100.3/32，下一跳为服务实例右侧接口。

作为静态路由，我们缺乏像BGP这样的协议所带来的动态性，尤其是面对故障时。

只要我们不引入“运行状况检查（Health Checks）”这样的功能，就可能带来这样的结果（出现静态路由的故障）。

状况检查是我们可以应用于VMI的功能组件——运行状况检查可验证VMI的活动性。

运行状况检查有很多不同种类，最简单的一项是ICMP检查。vRouter将ICMP echo请求发送到VMI，并等待echo应答。如果丢失的回复数超过配置的阈值，则将VMI声明为Down，并删除指向该VMI的所有路由（包括先前定义的那些静态路由）。

实际上，就像任何一个VNF都支持ping一样，任何VNF都将支持ICMP运行状况检查。当然，这种运行状况检查很慢并且不能提供快速收敛。为了更快地收敛，我们需要依靠BFD运行状况检查。使用BFD，我们可以更快地检测到故障，但VNF必须支持BFD。

阈值在运行状况检查对象内进行配置：

在本示例中，我们使用BFD，每秒发送一个BFD数据包。如果丢失了3个以上的数据包，则BFD宣告为down。

运行状况检查在服务实例对象内进行配置：

综上所述，我们可以使用路由策略来控制网络之间的泄漏。

此外，我们还可以定义静态路由，将其应用于VMI，并依靠运行状况检查（BFD）在出现故障时实现快速收敛。

下一步是什么？冗余。我们将在下篇文章中详细介绍。

细说TF服务链

1. 细说TF服务链丨一文讲透什么是服务链（多图）
2. 手把手教你配置服务链
3. 服务链后台的路由实现

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

第一篇：TF主要特点和用例
第二篇：TF怎么运作
第三篇：详解vRouter体系结构
第四篇：TF的服务链
第五篇：vRouter的部署选项
第六篇：TF如何收集、分析、部署？
第七篇：TF如何编排
第八篇：TF支持API一览
第九篇：TF如何连接到物理网络
第十篇：TF基于应用程序的安全策略

---

关于Tungsten Fabric：
Tungsten Fabric项目是一个开源项目协议，它基于标准协议开发，并且提供网络虚拟化和网络安全所必需的所有组件。项目的组件包括：SDN控制器，虚拟路由器，分析引擎，北向API的发布，硬件集成功能，云编排软件和广泛的REST API。

关于TF中文社区：
TF中文社区由中国的一群关注和热爱SDN的志愿者自发发起，有技术老鸟，市场老炮，也有行业专家，资深用户。将作为连接社区与中国的桥梁，传播资讯，提交问题，组织活动，联合一切对多云互联网络有兴趣的力量，切实解决云网络建设过程中遇到的问题。

---

关注微信：TF中文社区