细说TF服务链丨如何配置服务链的高级功能
细说TF服务链丨如何配置服务链的高级功能
作者：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服务链——
Tungsten Fabric 架构解析系列文章——
- 第一篇：TF主要特点和用例
- 第二篇：TF怎么运作
- 第三篇：详解vRouter体系结构
- 第四篇：TF的服务链
- 第五篇：vRouter的部署选项
- 第六篇：TF如何收集、分析、部署？
- 第七篇：TF如何编排
- 第八篇：TF支持API一览
- 第九篇：TF如何连接到物理网络
- 第十篇：TF基于应用程序的安全策略
本文系外文翻译，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。
本文系外文翻译，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。