细说TF服务链丨设计一个PBR+NAT的服务链



  • 作者:Umberto Manferdini 译者:TF编译组
    原文链接:https://iosonounrouter.wordpress.com/2020/08/07/designing-a-pbrnat-service-chain/

    在之前的文章中,我谈到了什么是服务链如何构建服务链,如何通过高级功能的配置具备高可用性。对于想了解服务链内部的人,还介绍了路由的工作方式

    现在,我们将把所有部分放在一起,并基于PBR服务链创建一个冗余NAT服务。

    让我们看一下拓扑图:
    59c2d765-67f5-431c-a7ed-435c0161fa95-image.png
    这个思路很简单:我们在左VN和右VN之间有一个网络策略,策略规则根据源地址匹配流量。这样,我们就可以在Tungsten Fabric场景下实现一个典型的PBR用例。

    在上面的示例中,我们配置了2条rules:每个都有其自己的服务实例(pbrnat1和pbrnat2)。服务实例具有引用vSRX接口的端口元组。vSRX负责从左向右“natting”流量。

    构建PBR的目的是为每个服务实例分配一个地址池(我们称其为左侧池)。例如,在这里服务实例pbrnat1分配了192.168.101.0/24的池(左侧池1),而pbrnat2分配了192.168.102.0/24(左侧池2)。

    有2个vSRX其实就够了,但这不能提供足够的容错能力。因此,我们添加了第三个vSRX作为备份vSRX。通过在服务实例中配置多个端口元组,并设置不同的vmi本地首选项值,来手动选择主路径和备份路径,从而进行冗余管理。

    这意味着,在正常情况下,源为192.168.101.0/24的流量将发送到服务实例pbrnat1并由vSRX1实现NAT。类似地,源为192.168.102.0/24的流量将发送到服务实例pbrnat2,并由vSRX2实现NAT。

    当vSRX1发生故障时,映射到服务实例pbrnat1的流量将发送到备份vSRX——vSRX3。vSRX2发生故障时同理。这或许意味着vSRX3可以管理所有的池。请记住,池已映射到服务实例,并且vSRX3端口属于所有服务实例,因为它是备份vSRX。
    让我们来看看如何配置用例并启用所有功能。

    首先,创建虚拟网络:
    22539983-6363-490b-a32e-34f46d35e7a5-image.png
    如你所见,左侧VN具有多个子网。子网101和102代表NAT池(左池);客户端VM附加到这些子网上。vSRX的左接口使用子网103。

    我们来创建连接到不同子网的端口:
    8729195a-27da-4357-8474-c95851713f69-image.png
    在此示例中,client1和client2是要NAT的“客户”,而web是类似Internet的目的地。

    所有其它接口都属于这3个vSRX——由它们组成服务链并执行NAT。

    接下来,我们创建服务模板:
    d41861a7-bbd5-4a39-996d-96b924f5da42-image.png
    这个对象非常标准:具有两个接口(左和右)的in-network类型。

    我们基于此模板创建服务实例:
    bbd3cbe8-531f-4f2d-a3f0-f8727d5015a2-image.png
    这里的关键是要有2个端口元组,总共4个接口。在此处查看冗余在服务链中的实现。两个接口属于vSRX1,本地优先级为100(active),另外两个接口被带到vSRX3,其vmi的本地优先级为200(backup)。

    服务实例pbrnat2的创建过程是一样的:
    c9c5e262-c37a-4330-a525-511a29a08213-image.png
    当然,我们假设vSRX VM已经启动并正在运行。

    现在,该创建策略了:
    9cbc5644-2d1b-43f4-9e73-eee9951fe7f8-image.png
    如预期的那样,我们有两个规则:一个匹配源192.168.101.0/24并将流量发送到服务实例pbrnat1(vsrx1主服务器),而一个匹配源192.168.102.0/24并将流量发送到服务实例pbrnat2(vsrx2主服务器)。

    策略同时附加到左网络和右网络:
    ce1eb3da-d2a5-44c4-9aaa-3011762010b6-image.png
    现在,服务链已经建立!

    是时候“丰富”它了。首先,我们要控制左右VN之间的泄漏。这是通过路由策略完成的:
    79d7b42e-eb57-4636-859b-a8ec4d084edf-image.png
    第一个策略仅允许默认路由,而第二个策略则拒绝所有内容。

    这种0/0的方式从右到左传递,以便客户可以访问Internet。在从左到右的方向上,无需泄漏任何东西。

    返回流量,需要遵循正确的池(post nat池)路由。这些池在vSRX(在NAT规则内)内配置,并且默认情况下对Tungsten Fabric未知。这意味着返回流量将无法正常工作。为了克服这个问题,我们创建了静态路由:
    74caec53-8c26-4d8b-bdf2-cc6d881f4e7a-image.png

    每个左池(pre nat池)都有一条静态路由。

    为了实验目的,我们还提供了一条默认的静态路由。

    还有什么?好吧,运行状况检查可以快速收敛:
    839a7405-f369-4767-aa45-f2b8d510c75d-image.png
    这是左侧的运行状况检查。我们将BFD(最快的运行状况检查类型)与微秒计时器一起使用(此处的收敛时间为3×300毫秒)。

    右侧的运行状况检查是相同的。

    最后,我们将所有这些都添加到服务实例中。这是pbrnat1的示例:
    8059a15a-0e2e-493d-86e7-87b911722e6c-image.png
    这里出现了很多信息!让我们一个一个看。

    服务实例引用2个实例和4个接口(2个端口元组)。这是预期内的,因为我们配置了2个端口元组:一个通向vSRX1(active),一个通向vSRX3(backup)。

    在左侧接口上,我们应用了default_only路由策略,以便从右到左的泄漏为0/0。在右侧接口上,我们应用了deny_all路由策略,因为该方向上无需泄漏任何内容。

    静态路由将应用于右接口。该静态路由指向分配给该服务实例(在本例中为192.168.101.0/24)的右侧池(post nat池)。

    最后,BFD运行状况检查将同时应用于左接口和右接口。

    好啦!现在我们拥有了具有容错能力和快速收敛性的PBR服务链!


Log in to reply