Tungsten Fabric入门宝典丨关于服务链、BGPaaS及其它

发布时间：2020-08-19 05:33:02 作者：TF中文社区
来源：ITPUB博客阅读：223

Tungsten Fabric入门宝典系列文章，来自技术大牛倾囊相授的实践经验，由TF中文社区为您编译呈现，旨在帮助新手深入理解TF的运行、安装、集成、调试等全流程。如果您有相关经验或疑问，欢迎与我们互动，并与社区极客们进一步交流。更多TF技术文章，请点击公号底部按钮＞学习＞文章合集。

作者：Tatsuya Naganawa 译者：TF编译组

服务链

尽管有很多用例，但NFVI将成为Tungsten Fabric最突出的用例之一，这是由于NFVI许多独特的功能，使其成为实现软件的基础。

其中最著名的功能就是服务链（service-chain），该功能可在不更改VNF IP的情况下管理流量，从而可以实时插入和删除VNF。

由于vRouter可以在内部包含VRF，因此它可以在VNF的每个接口上都具有VRF，并且可以通过虚假的下一跳处理流量，例如发送给下一个VNF。

Tungsten Fabric的服务链是通过这种方式实现的，因此一旦创建服务链，你将看到很多个VRF被创建，并且将插入下一跳，将流量发送到服务链中的下一个VNF。

VRF（在control的术语中是routing-instance）被命名为domain-name:project-name:virtual-network-name:routing-instance-name。在大多数情况下，virtual-network-name和routing-instance-name是相同的，但是服务链是该规则的一个例外

要设置一个服务链示例，可以按照以下视频中的步骤进行操作：

https://www.youtube.com/watch?v=h6qOqsPtQ7M

之后，你可以看到左侧virtual-network具有右侧virtual-network的前缀，并带有更新的下一跳，该前缀指向VNF的左侧接口，对于右侧virtual-network反之亦然。

注意：据我所知，在使用服务链v2时，仅使用“左”和“右”接口进行服务链计算，而“管理”和“其它”接口则被忽略

L2, L3, NAT

有许多具有不同流量类型集的VNF，因此NFVI的SDN也需要支持多种流量类型。

为此，Tungsten Fabric服务链支持三种流量类型，即l2，l3，nat。

l2服务链（也称为透明服务链）可以与透明VNF一起使用，透明VNF与网桥具有相似的功能，并基于arp响应发送报文。

尽管vRouter始终使用相同的mac地址（00:01:00:5e:00:00），

https://github.com/Juniper/contrail-controller/wiki/Contrail-VRouter-ARP-Processing#vrouter-mac-address

但这种情况是该规则的例外，VNF左侧的vRouter使用dest mac: 2:0:0:0:0:2发送流量，而VNF右侧的vRouter使用dest mac 1:0:0:0:0:1发送流量。因此，bridge-type的VNF会将流量发送到其接口的另一侧。

请注意，即使使用l2 vnf，左侧virtual-network和右侧virtual-network也需要具有不同的子网。这可能有点反常，但是由于vRouter可以进行l3路由，因此可以使用vRouter - L2VNF - vRouter，就像router - L2VNF – router是可以接受的一样。

另一方面，l3服务链（也称为in-network服务链）将在不更改mac地址的情况下将流量发送到VNF，因为在这种情况下，VNF将根据其目标IP进行路由（类似于路由器的行为）。除mac地址外，其行为与l2的情况几乎相同。

Nat服务链类似于l3服务链，因为它希望VNF根据目标IP进行路由。一个很大的区别是，它将右侧virtual-network的前缀复制到左侧virtual-network，但是不会将左侧virtual-network的前缀复制到右侧virtual-network！

因此左/右接口需要仔细选择，因为在这种情况下它是不对称的

这种服务链形式的典型用例是，在用于Internet访问的SNAT等情况下，VNF的左侧接口具有私网IP，而右侧接口具有全局IP。由于私网IP无法导出到Internet，在这种情况下，左侧virtual-network的前缀无法复制到右侧virtual-network。

ECMP，多VNF

服务链功能还支持ECMP设置，用于规模化部署。

配置基本相同，但需要将多个端口-元组分配给一个服务实例。

在这之后，你会发现，流量将根据5个数据包的5元组进行负载平衡。

多VNF也可以设置，如果将多个服务实例分配到一个网络策略上，则可以设置多VNF。

当使用l3服务链时，虽然可能会有反直觉，但需要将两个VNF分配给同一个虚拟网络。

因为所有来自VNF的数据包都会在服务链的独立VRF中，所以它们可以有相同的子网。

也支持同时使用l2和l3，不过在这种情况下，需要将l2 vnf分配到不同的虚拟网络中，其中一个网络政策是附加的。

在这篇博文中描述了设置示例： https://tungsten.io/building-and-testing-layer2-service-images-for-opencontrail/

子接口

这也是NFVI中使用的功能，因此这里我也要提一下。

VNF会基于各种原因发送带标签的报文。在这种情况下，如果vlan标签不同，则vRouter可以使用不同的VRF。

类似于Junos术语“set routing-instances routing-interface-name interface xxx”中的子接口

这里描述了具体操作：

https://www.youtube.com/watch?v=ANhBQe_DS2E

DPDK

vRouter具有使用DPDK与物理NIC交互的功能。

它将经常用于NFV类型的部署，因为基于纯Linux kernel的网络堆栈，要获得与典型VNF（本身可能使用DPDK或类似技术）相当的转发性能仍然不容易。

https://blog.cloudflare.com/how-to-receive-a-million-packets/

要通过ansible-deployer启用此功能，需要设置这些参数。



bms1:

  roles:

    vrouter:

      AGENT_MODE: dpdk

      CPU_CORE_MASK: “0xe” 
## coremask for forwarding core (
Note: please don't include first core in numa to reach optimal performance :( )

      SERVICE_CORE_MASK: “0x1” 
## this is for non-forwarding thread, so isolcpu for this core is not needed

      DPDK_CTRL_THREAD_MASK: “0x1” 
## same as SERVICE_CORE_MASK

      DPDK_UIO_DRIVER: uio_pci_generic 
## uio driver name

      HUGE_PAGES: 16000 
## number of 2MB hugepages, it can be smaller

当设置为AGENT_MODE: dpdk时，ansible-deployer将会安装一些容器，例如vrouter-dpdk——这是一个针对物理NIC运行PMD的进程。因此在这种情况下，将基于DPDK实现从vRouter到物理NIC的转发。

注意：

1. 由于vRouter链接到PMD的数量有限，因此要使用某些特定的NIC，可能需要重新构建vRouter

https://github.com/Juniper/contrail-vrouter/blob/master/SConscript#L321

2. 对于某些NIC（例如XL710），不能使用uio_pci_generic。在这种情况下，需要改用vfio-pci

https://doc.dpdk.org/guides-18.05/rel_notes/known_issues.html#uio-pci-generic-module-bind-failed-in-x710-xl710-xxv710

由于在这种情况下，vRouter的转发平面不在kernel空间中，因此无法使用tap设备从VM获取报文。为此，QEMU具有“vhostuser”的功能，用于在用户空间中将报文发送到dpdk进程。当vRouter配置为AGENT_MODE: dpdk时，nova-vif-driver将自动创建vhostuser vif，而不是创建用于kernel vRouter的tap vif。

从VM方面看，它看起来仍然像virtio，因此可以使用常规的virtio驱动程序与DPDK vRouter进行通信。

一个警告是，当QEMU将要连接到vhostuser界面时，qemu还需要为此提供巨大的支持。使用OpenStack时，此knob将为每个VM分配大量页面。

为了达到最佳性能，kernel和dpdk进程本身都有很多调整参数。对我来说，在kernel方面以下两篇文章是最有帮助的。

https://www.redhat.com/en/blog/tuning-zero-packet-loss-red-hat-openstack-platform-part-1

https://www.redhat.com/en/blog/going-full-deterministic-using-real-time-openstack

cat /proc/sched_debug也可用于查看核心隔离是否运行良好

而在vRouter方面，这一点可能需要注意。

1. vRouter将使用基于5-tuple的核心负载均衡，因此为了获得最佳性能，可能需要增加流的数量

https://www.openvswitch.org/support/ovscon2018/6/0940-yang.pptx

注意：当使用vrouter-dpdk时，使用untagged数据包可能会带来更多的吞吐量（这意味着在不使用--vlan_tci的情况下提供vrouter-dpdk）

BGPaaS

BGPaaS也是Tungsten Fabric中比较独特的功能，该功能用于在VNF中插入VRF的路由。

从某种意义上说，它有点类似于AWS VPN网关，因为它会自动从VPC路由表中获取路由

从操作角度来看，使用vRouter的网关IP和服务IP，vRouter中的VNF将具有IPV4 bgp对等方。

一个值得注意的用例是设置ipsec VNF，它可以通过VPN网关连接到公共云。在这种情况下，VPC的路由表将被复制到VNF，并将通过BGPaaS复制到vRouter的VRF，因此，当在公共云的VPC中新添加修改的子网时，所有前缀均会被正确分配。

Service Mesh

Istio运行良好，多集群也是其中很有趣的主题。

https://www.youtube.com/watch?v=VSNc9qd2poA

https://istio.io/docs/setup/kubernetes/install/multicluster/vpn/

Tungsten Fabric入门宝典系列文章——

首次启动和运行指南
TF组件的七种“武器”
编排器集成
关于安装的那些事（上）
关于安装的那些事（下）
主流监控系统工具的集成
开始第二天的工作
8个典型故障及排查Tips
关于集群更新的那些事
说说L3VPN及EVPN集成

Tungsten Fabric 架构解析 系列文章——

第一篇： TF主要特点和用例
第二篇： TF怎么运作
第三篇：详解vRouter体系结构
第四篇： TF的服务链
第五篇： vRouter的部署选项
第六篇： TF如何收集、分析、部署？
第七篇： TF如何编排
第八篇： TF支持API一览
第九篇： TF如何连接到物理网络
第十篇： TF基于应用程序的安全策略

Tungsten Fabric入门宝典丨关于服务链、BGPaaS及其它

Tungsten Fabric入门宝典丨关于服务链、BGPaaS及其它

TF组件的七种“武器”

关于集群更新的那些事

说说L3VPN及EVPN集成

相关阅读