作者：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服务链
- 细说TF服务链丨一文讲透什么是服务链（多图）
- 手把手教你配置服务链
- 服务链后台的路由实现
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中文社区