作者： Umberto Manferdini 译者：TF编译组
上一篇文章中，我配置了最简单的服务链。现在，是时候了解路由实际上是如何实现的了。
我们的拓扑结构是这样一条简单的服务链：
让我们看一下路由表。
从“分离的”VN开始：没有策略，没有服务链。
在本实例中，路由表仅包含该虚拟网络的地址。
接下来，应用策略，但不添加任何服务实例：
现在，左侧网络还包括来自右侧网络的路由：
在这背后是什么？Route Target！
为了解更多信息，我将在控制节点上使用Introspect并浏览路由表（模块为bgp_peer，然后使用ShowRoute family请求）。
创建虚拟网络后，会自动为其分配Route Target。即使没有配置Route Target，仍然有一个VN。这种Route Target的值高于800万，因此很容易识别。
指定左侧VN为target:64520:8000059
指定右侧VN为target:64520:8000060
一旦我们应用网络策略，允许这两个VN之间进行通信，Tungsten Fabric就会自动调整导入Route Target策略。
左侧VN现在会导入“8000060”，这意味着它将导入右侧VN的路由：
右侧VN的更新方式类似，不过它将导入RT“8000059”，即左侧VN RT：
到最后，网络策略看起来似乎只是利用Route Target执行泄漏。
那么，为什么在创建虚拟网络时，我们要花时间在网络策略上，而不仅仅是配置适当的Route Target，然后导入Route Target策略就好了？
我们知道，网络策略允许创建L4规则。通过网络策略，可以决定允许TCP通信，以及阻止UDP通信。这就是重点，我们可以创建服务链。
开始吧！最后一步，服务链：
查看左侧VN导入Route Target政策：
这很有趣……我们知道还有两个虚拟网络：
–左侧，原始VN出来
–左侧服务，一个辅助VN“映射”到了服务实例
左侧VN导出RT“8000059”，而左侧服务则导出RT“8000061”。这两个VN相互导入RT。这意味着它们之间有泄漏！
来看一下右侧的情况：
我们看到了类似的东西：右侧和右侧服务相互导入RT。
没有服务实例，左侧VN将导入右侧VN，反之亦然。现在，此机制仅限于左侧和左侧服务（或右侧和右侧服务）。那么，从右到左的路由如何到达？
看起来，RT泄漏并不简单。
在这种情况下，我们必须谈论路由重新分配。这意味着Tungsten Fabric将重新分配路由。仔细考虑一下，这是有道理的。
假如没有服务实例，可以按原样从右向左复制路由，反之亦然。
另一方面，在服务实例起作用的情况下，当一条路由从右侧“泄露”到左侧时，下一跳必须更新，因为它必须指向服务实例vmi。
那么这是如何工作的呢？让我们看看右侧VN路由：192.168.20.3/32。
跟以往一样，该路由有两个副本：XMPP和BGP。
查看这些路由更多的详细信息：
这里要注意的是，该路由具有一个辅助表，是的，它是右侧服务！这里右侧到右侧服务的泄露，是由于我们之前看到的导入Route Target策略。可以看到，BGP路由（第二个）导出RT“8000060”，而该RT是由右侧服务导入的。
现在，我们转到左侧服务路由表：
仍然有两条路由，但XMPP的那一条已被服务链的那一条所取代。
此路由将左侧VN作为辅助表：
下图表示了路由的传播：
当流量从左向右移动时，会发生以下情况：
回程流量利用了现有流量。
是不是有点复杂？可能是的……但是考虑一下，我们为创建这条链实际配置了什么，很明显Tungsten Fabric是如何隐藏了所有的复杂性！
下一次，我将开始研究高级服务实例的设置。
细说TF服务链——
Tungsten Fabric 架构解析系列文章——
第一篇：TF主要特点和用例
第二篇：TF怎么运作
第三篇：详解vRouter体系结构
第四篇：TF的服务链
第五篇：vRouter的部署选项
第六篇：TF如何收集、分析、部署？
第七篇：TF如何编排
第八篇：TF支持API一览
第九篇：TF如何连接到物理网络
第十篇：TF基于应用程序的安全策略
5181
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
