作者: Umberto Manferdini 译者:TF编译组
上一篇文章中,我配置了最简单的服务链。现在,是时候了解路由实际上是如何实现的了。
让我们看一下路由表。
从“分离的”VN开始:没有策略,没有服务链。
在这背后是什么?Route Target!
为了解更多信息,我将在控制节点上使用Introspect并浏览路由表(模块为bgp_peer,然后使用ShowRoute family请求)。
创建虚拟网络后,会自动为其分配Route Target。即使没有配置Route Target,仍然有一个VN。这种Route Target的值高于800万,因此很容易识别。
指定右侧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服务链
细说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中文社区