标签：技术实现

技术手册-Kolla-Ansible：在容器环境中部署OpenStack

关注星融元

OpenStack简介

OpenStack是一个云操作系统，它控制整个数据中心的大型计算、存储和网络资源池，所有这些资源都通过一个仪表板进行管理，该仪表板赋予管理员控制权，同时允许用户通过web界面提供资源。

它为私有云和公有云提供可扩展的弹性的云计算服务，提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。

Kolla-Ansible简介

Kolla旨在为运行OpenStack提供生产就绪的容器和部署工具。

Kolla-Ansible是Kolla的子项目，该项目使用Ansible部署Kolla容器映像。

Kolla-Ansible是开箱即用的工具，即使你是个新手也可以快速部署OpenStack，也允许你根据需求定制化的部署。

目标

在容器中部署OpenStack最大的特点就是升级，用户基本是无感知的状态下完成。同时可以实现本地与云端一致，一次开发随处运行，通过迁移到不同的设备，快速的完成部署和升级操作。

本文将以详细操作指导的方式，给出一种在Docker容器环境中部署OpenStack的指导方法。

环境准备

两台server，一台作为controller，另一台作为compute节点，操作系统CentOS 7.6.1810 镜像CentOS-7-x86_64-DVD-1810.iso。服务器具体配置要求如下：

2个千兆网口
至少8G内存
磁盘至少40G
计算节点的BISO中开启CPU嵌套虚拟化(INTEL叫VT-x，AMD的叫AMD-V)

Kolla-Ansible部署过程

关闭SELinux 【控制节点、计算节点】

SELinux不关闭的情况下无法实现，会限制ssh免密码登录

[root@localhost ~]#setenforce 0

[root@localhost ~]# sed -i ‘s/SELINUX=enforcing/SELINUX=disabled/g’ /etc/sysconfig/selinux

关闭防火墙【控制节点、计算节点】

防止安装时出现各个组件的端口不能访问的问题

[root@localhost ~]#systemctl stop firewalld && systemctl disable firewalld

禁用宿主机的 Libvirt 服务

大多数操作系统会默认启动 Libvirt，但使用 Kolla 来部署 OpenStack 的话，Libvirt 应该在容器中运行并管理虚拟机。所以宿主机的 Libvirt 需要被关闭，以免造成冲突。

[root@localhost ~]#systemctl stop libvirtd.service
[root@localhost ~]#systemctl disable libvirtd.service

设置主机名，hosts文件【控制节点、计算节点】

控制节点

[root@localhost ~]#hostname controller
[root@localhost ~]#echo “controller”> /etc/hostname

计算节点根据节点名称修改

[root@localhost ~]#vim /etc/hosts
192.168.4.2 controller
192.168.4.150 computer1

修改网卡名称【控制节点、计算节点】

说明：网卡名字不是必须改，保持各服务器使用的网卡名称一样。

网卡1:

[root@localhost ~]#cd /etc/sysconfig/network-scripts
[root@localhost ~]#vim ifcfg-enp6s0f0
IPADDR=192.168.1.*
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
NAME=eno1
DEVICE=eno1

网卡2:

[root@localhost ~]#cd /etc/sysconfig/network-scripts
[root@localhost ~]#vim ifcfg-enp6s0f1
IPADDR=192.168.2*
NETMASK=255.255.255.0
GATEWAY=192.168.21
NAME=eno2
DEVICE=eno2

修改网卡文件名称:

[root@localhost ~]#mv ifcfg-enp6s0f0 ifcfg-eno1
[root@localhost ~]#mv ifcfg-enp6s0f1 ifcfg-eno2

修改net配置文件

[root@localhost ~]#vi /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM==”net”,ACTION==”add”,DRIVERS==”?*”,ATTR{address}==”78:24:af:85:0c:ac”,ATTR{type}==”1″, NAME=”eno1″
SUBSYSTEM==”net”,ACTION==”add”,DRIVERS==”?*”,ATTR{address}==”78:24:af:85:0c:ad”,ATTR{type}==”1″, NAME=”eno2″

ATTR和服务器两网口MAC地址保持一致

重启服务器

[root@localhost ~]#reboot

重启网络服务

[root@localhost ~]#systemctl restart network

安装【控制节点、计算节点】

[root@localhost ~]#yum install -y epel-release
[root@localhost ~]#yum install -y python-pip
[root@localhost ~]#pip install -U pip

安装编译环境【控制节点】

[root@controller ~]#yum install -y python-devel libffi-devel gcc openssl-devel libselinux-python

安装ansible【控制节点】

[root@controller ~]#pip install -U ansible

l 安装docker【控制节点、计算节点】

[root@localhost ~]#tee /etc/yum.repos.d/docker.repo <<-‘EOF’
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/7/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF
[root@localhost ~]#yum install -y docker-engine docker-engine-selinux

问题1 安装docker失败，提示与其他安装包冲突Error: docker-engine-selinux conflicts with 2:container-selinux-2.107-3.el7.noarch

解决方法如下：

[root@compute1 ~]#rpm -qa |grep container-selinux-2.107-3.el7.noarch
[root@compute1 ~]#yum -y remove container-selinux-2.107-3.el7.noarch

设置Docker【控制节点、计算节点】

[root@localhost ~]#mkdir /etc/systemd/system/docker.service.d
[root@localhost ~]#tee /etc/systemd/system/docker.service.d/kolla.conf << ‘EOF’
[Service]
MountFlags=shared
EOF

重启相关服务【控制节点、计算节点】

[root@localhost ~]#systemctl daemon-reload
[root@localhost ~]#systemctl enable docker
[root@localhost ~]#systemctl restart docker

安装模块【控制节点、计算节点】

[root@localhost ~]#pip install docker

安装【控制节点】

[root@controller ~]#yum install git

安装kolla-ansible【控制节点】

[root@controller ~]#pip install kolla-ansible

如果报如下错误

Cannot uninstall ‘PyYAML’. It is a distutils installed project and thus we

cannot accurately determine which files belong to it which would lead to only a

partial uninstall.

[root@controller ~]#rm -rf /usr/lib64/python2.7/site-packages/PyYAML*

拷贝配置文件【控制节点】

[root@controller ~]#cp -r /usr/share/kolla-ansible/etc_examples/kolla /etc/kolla/

[root@controller ~]#cp /usr/share/kolla-ansible/ansible/inventory/* /home/

配置免密登录【控制节点】

[root@controller ~]#ssh-keygen                        #一路回车
[root@controller ~]#ssh-copy-id controller         #回车后输入服务器密码
[root@controller ~]#ssh-copy-id computer1          #回车后输入服务器密码

存储节点配置【计算节点】

(演示版本可以跳过此步骤)

要启动cinder存储服务，需先添加一块新的硬盘，然后创建pv、vg

[root@computer1 ~]#pvcreate /dev/sdb
[root@computer1 ~]#vgcreate cinder-volumes /dev/sdb //vg名取名为 cinder-volumes，这里主要跟 kolla配置文件里vg名一致

问题1 如果出现创建不了pv

解决方法如下：

[root@compute1 ~]#pvcreate devsdb
Device /dev/sdb excluded by a filter.

解决：

[root@compute1 ~]#dd if=/dev/urandom of=/dev/sdb bs=512 count=64
64+0 records in
64+0 records out
32768 bytes (33 kB) copied, 0.00760562 s, 4.3 MB/s
[root@compute1 ~]#pvcreate /dev/sdb
Physical volume “/dev/sdb” successfully created.

重启服务【计算节点】

[root@compute1 ~]#systemctl restart lvm2-lvmetad.service

修改【控制节点】

[root@controller ~]#vim /home/multinode
[control]
controller
[network]
controller
[inner-compute]
[external-compute]
computer1
[compute:children]
inner-compute
external-compute
[storage]
computer1
[monitoring]
controller
[deployment]
controller

获取docker镜像【控制节点、计算节点】

使用kolla官方镜像源

[root@localhost ~]#vim /etc/kolla/globals.yml
kolla_install_type: “binary”
openstack_release: “stein”
docker_namespace: “kolla”

下载镜像包

[root@controller ~]#kolla-ansible pull -i /home/multinode

修改全局配置文件globals.yml【控制节点】

管理网口eno1,外网网口eno2

如果采用cinder磁盘存储

kolla_base_distro: “centos”

kolla_install_type: “binary”
openstack_release: “stein”
kolla_internal_vip_address: “192.168.4.2”
# Valid options are [ qemu, kvm, vmware, xenapi ]
nova_compute_virt_type: “kvm”
network_interface: “eno1”
api_interface: “{{ network_interface }}”
neutron_external_interface: “eno2”
neutron_plugin_agent: “openvswitch”
enable_cinder: “yes”
enable_cinder_backend_iscsi: “no”
enable_cinder_backend_lvm: “yes”
enable_haproxy: “yes”
enable_heat: “yes”
glance_enable_rolling_upgrade: “no”
ironic_dnsmasq_dhcp_range:
tempest_image_id:
tempest_flavor_ref_id:
tempest_public_network_id:
tempest_floating_network_name:

如果采用外部ceph存储：

kolla_base_distro: “centos”


kolla_install_type: “binary”
openstack_release: “stein”
kolla_internal_vip_address: “192.168.4.2”
# Valid options are [ qemu, kvm, vmware, xenapi ]
nova_compute_virt_type: “qemu”
nova_backend_ceph: “yes”
network_interface: “eno1”
api_interface: “{{ network_interface }}”
neutron_external_interface: “eno2”
neutron_plugin_agent: “openvswitch”
enable_ceph: “no”
enable_cinder_backup: “yes”
cinder_backup_driver: “ceph”
enable_cinder: “yes”
enable_cinder_backend_iscsi: “no”
enable_cinder_backend_lvm: “no”
enable_haproxy: “yes”
enable_heat: “yes”
enable_sahara: “yes”
enable_trove: “yes”
cinder_backend_ceph: “yes”
glance_backend_ceph: “yes”
glance_enable_rolling_upgrade: “no”
ironic_dnsmasq_dhcp_range:
tempest_image_id:
tempest_flavor_ref_id:
tempest_public_network_id:
tempest_floating_network_name:

生成密码文件passwords.yml【控制节点】

这个密码文件可以使用工具自动生成，也可以手动输入但是手动输入需要注意格式，在：后需要空一格

再输入；而且ssh_key也比较麻烦所以推荐使用工具自动生成但是直接输入

[root@controller ~]#kolla-genpwd

修改dashboard登录密码

[root@controller ~]#vi /etc/kolla/passwords.yml

keystone_admin_password: admin

修改部署文件multinode【控制节点】

[root@controller ~]#vim /home/multinode
[control]
controller
[network]
controller
[inner-compute]
[external-compute]
computer1
[compute:children]
inner-compute
external-compute
[monitoring]
controller
[storage]
computer1
[deployment]
localhost ansible_connection=local

检查配置【控制节点】

[root@controller ~]#kolla-ansible prechecks -i /home/multinode

配置SchedNova主机基础环境【控制节点】

[root@controller ~]#kolla-ansible -i /home/multinode bootstrap-servers

部署OpenStack【控制节点】

[root@controller ~]#kolla-ansible deploy -i /home/multinode

验证OpenStack安装【控制节点】

[root@controller ~]#kolla-ansible post-deploy -i /home/multinode

OpenStack更新【控制节点】

### 修改镜像版本（此处不用更新,以后想更新版本再更新）

[root@controller ~]# vim /etc/kolla/globals.yml
openstack_release: “stein”
[root@controller ~]# kolla-ansible upgrade -i /home/multinode

重启所有应用【控制节点】

[root@controller ~]#kolla-ansible -i /home/multinode reconfigure

环境还原【控制节点】

#如果安装有错误，想重新安装，可以选择如下操作

##将删除所有容器和卷

[root@controller ~]#kolla-ansible destroy –yes-i-really-really-mean-it -i /home/multinode

生成 admin-openrc.sh【控制节点】

[root@controller ~]#kolla-ansible post-deploy

初始demo【控制节点】

执行后会自动下载cirros镜像, 创建网络, 并创建一批测试虚拟机.

[root@controller ~]#/usr/share/kolla-ansible/init-runonce

查询登录密码【控制节点】

[root@controller ~]#grep admin /etc/kolla/passwords.yml

安装OpenStack命令行客户端【控制节点】

[root@controller ~]#pip install python-openstackclient

创建实例到指定计算节点

查看有效区域

[root@controller ~]#openstack availability zone list

查看有效主机列表

[root@controller ~]#openstack host list

查看有效计算节点列表

[root@controller ~]#openstack hypervisor list

查询网络id

[root@controller ~]#openstack network list

查看安全组

[root@controller ~]#openstack security group list

创建flavor

[root@controller ~]#openstack flavor create –id 0 –vcpus 1 –ram 64 –disk 1 m1.nano
[root@controller ~]#openstack flavor create –id 1 –vcpus 1 –ram 512 –disk 1 m1.tiny
[root@controller ~]#openstack flavor create –id 2 –vcpus 1 –ram 2048 –disk 20 m1.small
[root@controller ~]#openstack flavor create –id 3 –vcpus 2 –ram 4096 –disk 40 m1.medium
[root@controller ~]#openstack flavor create –id 4 –vcpus 4 –ram 8192 –disk 80 m1.large
[root@controller ~]#openstack flavor create –id 5 –vcpus 8 –ram 16384 –disk 160 m1.xlarg

创建实例

[root@controller ~]#openstack server create –flavor m1.nano \
–image cirros \
–nic net-id=88b84388-40d2-48d9-b4ec-ab0dfa9b244e \
–security-group 5431def1-8856-4e48-ab02-50b9d459f9b1 \
–key-name mykey \
–availability-zone nova:computer2:computer2 instance2

–flavor 实例类型

–image 镜像

–nic 网络 net-id网络id 第4步查得

–availability-zone nova:compute1:compute1 前三步查得

compute1为指定计算节点。

结论

从上面的安装过程我们发现Kolla-Ansible来完成OpenStack安装过程非常的简洁，不需要过多修改OpenStack的配置文件，从而可以很轻松的完成部署和升级等操作。

参考资料

OpenStack官网： openstack.org
Kolla-Ansible项目官网：https://wiki.openstack.org/wiki/Kolla#Kolla
Kolla-Ansible官网安装：https://docs.openstack.org/kolla-ansible/latest/

技术手册-虚拟扩展本地局域网协议VXLAN

关注星融元

VXLAN全称Virtual eXtensible Local Area Network即虚拟扩展局域网，是由IETF定义的NVO3（Network Virtualization over Layer 3）标准技术之一，是对传统VLAN协议的一种扩展。VXLAN的特点是将L2的以太帧封装到UDP报文（即L2 over L4）中，并在L3网络中传输。

VXLAN的产生背景

数据中心规模的壮大，虚拟机数量的快速增长与虚拟机迁移业务的日趋频繁，给传统的“二层+三层”数据中心网络带来了新的挑战：

虚拟机规模受网络设备表项规格的限制

对于同网段主机的通信而言，报文通过查询MAC表进行二层转发。服务器虚拟化后，数据中心中VM的数量比原有的物理机发生了数量级的增长，伴随而来的便是虚拟机网卡MAC地址数量的空前增加。一般而言，接入侧二层设备的规格较小，MAC地址表项规模已经无法满足快速增长的VM数量。

传统网络的隔离能力有限

VLAN作为当前主流的网络隔离技术，在标准定义中只有12比特，也就是说可用的VLAN数量只有4096。对于公有云或其它大型虚拟化云计算服务这种动辄上万甚至更多租户的场景而言，VLAN的隔离能力显然已经力不从心。

虚拟机迁移范围受限

虚拟机迁移，顾名思义，就是将虚拟机从一个物理机迁移到另一个物理机，但是要求在迁移过程中业务不能中断。要做到这一点，需要保证虚拟机迁移前后，其IP地址、MAC地址等参数维持不变。这就决定了，虚拟机迁移必须发生在一个二层域中。而传统数据中心网络的二层域，将虚拟机迁移限制在了一个较小的局部范围内。值得一提的是，通过堆叠、SVF、TRILL等技术构建物理上的大二层网络，可以将虚拟机迁移的范围扩大。但是，构建物理上的大二层，难免需要对原来的网络做大的改动，并且物理大二层网络的范围依然会受到种种条件的限制。

VXLAN采用L2 over L4（MAC-in-UDP）的报文封装模式，将二层报文用三层协议进行封装，可实现二层网络在三层范围内进行扩展，同时满足数据中心大二层虚拟迁移和多租户的需求。

VXLAN的发展历程

协议最早由VMware、Arisa网络、Cisco提出，后期加入华为、博科、Red Hat、Intel等公司支持，IETF于2012年8月发布第一个RFC Internet Draft版本，最新的标准是2014年8月RFC 7348。

VXLAN的相关概念

NVO3（Network Virtualization Over Layer3 3层之上的网络虚拟化）

基于IP Overlay的虚拟局域网络技术统称为NVO3。

NVE(Network Virtrualization Edge网络虚拟边缘节点）

是实现网络虚拟化的功能实体，VM里的报文经过NVE封装后，NVE之间就可以在基于L3的网络基础上建立起L2虚拟网络。网络设备实体以及服务器实体上的VSwitch都可以作为NVE。

VTEP（VXLAN Tunnel Endpoints，VXLAN隧道端点）

VXLAN网络的边缘设备，是VXLAN隧道的起点和终点，VXLAN报文的相关处理均在这上面进行。VTEP既可以是一个独立的网络设备，也可以是虚拟机所在的服务器。

VNI（VXLAN Network Identifier，VXLAN 网络标识符）

VNI类似VLAN ID，用于区分VXLAN段，不同VXLAN段的虚拟机不能直接二层相互通信。一个VNI表示一个租户，即使多个终端用户属于同一个VNI，也表示一个租户。VNI由24比特组成，支持多达16M（(2^24-1)/1024^2）的租户。

VXLAN隧道

“隧道”是一个逻辑上的概念，它并不新鲜，比如大家熟悉的GRE。说白了就是将原始报文“变身”下，加以“包装”，好让它可以在承载网络（比如IP网络）上传输。从主机的角度看，就好像原始报文的起点和终点之间，有一条直通的链路一样。而这个看起来直通的链路，就是“隧道”。顾名思义，“VXLAN隧道”便是用来传输经过VXLAN封装的报文的，它是建立在两个VTEP之间的一条虚拟通道。

BD（bridge domain）,vxlan转发二层数据报文的广播域，是承载vxlan数据报文的实体。类似于传统网络中VLAN的概念，只不过在VXLAN网络中，它有另外一个名字BD。不同的VLAN是通过VLAN ID来进行区分的，那不同的BD是通过VNI来区分的。
VXLAN报文格式

VXLAN报文格式

图1： VXLAN报文格式

VXLAN标准报文格式

图2：VXLAN标准报文格式

VXLAN的工作原理

VXLAN网络中的通信过程

结合如下示例简要说明VXLAN网络中的通信过程：

VXLAN通信过程

图3：VXLAN通信过程

图3中 Host-A 和 Host-B 位于 VNI 10 的 VXLAN，通过 VTEP-1 和 VTEP-2 之间建立的 VXLAN 隧道通信。

数据传输过程如下：

Host-A 向 Host-B 发送数据时，Host-B 的 MAC 和 IP 作为数据包的目标 MAC 和 IP，Host-A 的 MAC 作为数据包的源 MAC 和 IP，然后通过 VTEP-1 将数据发送出去。
VTEP-1 从自己维护的映射表中找到 MAC-B 对应的 VTEP-2，然后执行 VXLAN 封装，加上 VXLAN 头，UDP 头，以及外层 IP 和 MAC 头。此时的外层 IP 头，目标地址为 VTEP-2 的 IP，源地址为 VTEP-1 的 IP。同时由于下一跳是 Router-1，所以外层 MAC 头中目标地址为 Router-1 的 MAC。
数据包从 VTEP-1 发送出去后，外部网络的路由器会依据外层 IP 头进行包路由，最后到达与 VTEP-2 连接的路由器 Router-2。
Router-2 将数据包发送给 VTEP-2。VTEP-2 负责解封数据包，依次去掉外层 MAC 头，外层 IP 头，UDP 头和 VXLAN 头。
VTEP-2 依据目标 MAC 地址将数据包发送给 Host-B。

上面的流程我们看到 VTEP 是 VXLAN 的最核心组件，负责数据的封装和解封。

隧道也是建立在 VTEP 之间的，VTEP 负责数据的传送。

VTEP节点工作机制

通过以上通信步骤的描述可以看到，VTEP节点在VXLAN网络通信中起到了至关重要的作用。在VXLAN网络通信中，VTEP节的职责主要有3项：

将虚拟网络通信的数据帧添加VXLAN头部和外部UDP和IP首部。
将封装好的数据包转发给正确的VTEP节点。
收到其他VTEP发来的VXLAN报文时，拆除外部IP、UDP以及VXLAN首部，然后将内部数据包交付给正确的终端。

对于功能2)的实现，即VXLAN数据包的转发过程。当VTEP节点收到一个VXLAN数据包时，需要根据内部以太网帧的目的MAC地址找到与拥有该目的地址的终端直接相连的VTEP地址，因此，这里需要一个目的MAC地址和VTEP节点IP地址的映射关系，VTEP节点利用一个转发表来存储此映射关系。转发表的格式为：<VNI, Inner Dst MAC,VTEP IP>，即给定VNI和目的MAC地址后映射到一个VTEP IP地址。

需要说明的是，映射VTEP节点IP地址时，之所以需要VNI的信息，是因为当存在多租户的情况下，各个租户将会独立组网，此时，多个租户设定的MAC地址有一定的概率会出现重叠，此时我们必须保证每个租户的网络都能独立地正常通信，因此，在为每个租户配置唯一的一个VNI的情况下，给定VNI和目的MAC地址，唯一确定一个VTEP地址。

下图4是一个样例，对于下图中的网络拓扑，分别给出了两个VTEP节点的转发表：

VTEP节点工作过程

图4：VTEP节点工作过程

上图中给出了6个终端，分别属于2个租户，其中，终端T1、T2和T4属于租户1，分配VNI为1，终端T3、T5和T6属于租户2，分配VNI为2，两个VTEP节点的转发表已在图中给出。

每一个VTEP节点都必须拥有完整的转发表才可以正确地进行转发的功能，转发表的学习过程可以基于这样一种简单的策略：通过ARP报文学习，当收到终端发送的数据帧时，首先根据收到数据的端口判定数据发送方的VNI值，根据VNI和数据帧中的目的MAC查找对应的VTEP节点，如果查找成功，则转发，否则，在当前VXLAN网络中广播ARP请求报文，这样，连接目的MAC终端的VTEP节点就会发送ARP回答报文，这样就学习到了新的转发表项。

需要说明的是，在多租户的环境下，基于信息安全等因素，各个租户的流量必须实现隔离，因此在发送广播ARP请求报文时，不可以直接在多租户的环境中广播，必须保证只有当前VXLAN网络的终端可以收到广播报文，因此，和物理网络中的ARP广播请求的实现有所不同，这里需要通过IP组播机制来模拟广播。

因此，VTEP节点还需要保存对应于每个租户的VNI值的组播域，即对于每一个VNI值，存储包含当前VXLAN网络中终端的所有VTEP节点的IP，用于ARP广播时的组播操作。

VXLAN二层网关与三层网关

VXLAN二层网关：用于终端接入VXLAN网络，也可用于同一VXLAN网络的子网通信。
VXLAN三层网关：用于VXLAN网络中跨子网通信以及访问外部网络。

VXLAN集中式网关与分布式网关

根据三层网关部署方式的不同，VXLAN三层网关又可以分为集中式网关和分布式网关。

VXLAN集中式网关

集中式网关是指将三层网关集中部署在一台设备上，如下图所示，所有跨子网的流量都经过这个三层网关转发，实现流量的集中管理。

图5：

部署集中式网关的优点和缺点如下：

优点：对跨子网流量进行集中管理，网关的部署和管理比较简单。
缺点：转发路径不是最优：同一二层网关下跨子网的数据中心三层流量都需要经过集中三层网关绕行转发（如图中橙色虚线所示）。
ARP表项规格瓶颈：由于采用集中三层网关，通过三层网关转发的终端的ARP表项都需要在三层网关上生成，而三层网关上的ARP表项规格有限，这不利于数据中心网络的扩展。
VXLAN分布式网关

VXLAN分布式网关是指在典型的“Spine-Leaf”组网结构下，将Leaf节点作为VXLAN隧道端点VTEP，每个Leaf节点都可作为VXLAN三层网关（同时也是VXLAN二层网关），Spine节点不感知VXLAN隧道，只作为VXLAN报文的转发节点。如下图所示，Server1和Server2不在同一个网段，但是都连接到一个Leaf节点。Server1和Server2通信时，流量只需要在Leaf1节点进行转发，不再需要经过Spine节点。

部署分布式网关时：

Spine节点：关注于高速IP转发，强调的是设备的高速转发能力。
Leaf节点：作为VXLAN网络中的二层网关设备，与物理服务器或VM对接，用于解决终端租户接入VXLAN虚拟网络的问题。作为VXLAN网络中的三层网关设备，进行VXLAN报文封装/解封装，实现跨子网的终端租户通信，以及外部网络的访问。

VXLAN分布式网关

图6：VXLAN分布式网关

VXLAN分布式网关具有如下特点：

同一个Leaf节点既可以做VXLAN二层网关，也可以做VXLAN三层网关，部署灵活。

Leaf节点只需要学习自身连接服务器的ARP表项，而不必像集中三层网关一样，需要学习所有服务器的ARP表项，解决了集中式三层网关带来的ARP表项瓶颈问题，网络规模扩展能力强。

VXLAN在星融元交换机上的配置实例

下面实例中星融元的两台CX306交换机通过配置BGP EVPN来实现VXLAN网络的建立。

CX306交换机通过配置BGP EVPN来实现VXLAN网络的建立

全文请注册/登录后获取：https://asterfusion.com/d-20220617/

技术手册-防火墙IP TABLES

关注星融元

IP Tables相关名词释义

iptables：iptables是一个用户空间工具，系统管理员可以通过它配置Linux内核防火墙的IP数据包的过滤规则，而这些规则的具体实现是由内核空间的netfilter完成的；
netfilter：netfilter是4.x版本Linux内核开始引入的一个子系统，它作为一个通用的、抽象的框架，提供一套完整的hook函数管理机制，实现了诸如数据包过滤、网络地址转换和基于协议类型的连接跟踪等功能；
hook函数：Linux内核中的有一套hook函数机制，可在不同hook点位置监控网络数据包，并执行丢弃、修改等操作，Linux内核的网络防火墙就是通过此机制实现的。

IP Tables的发展历史

目前iptables已在2.4、2.6及3.0版本的Linux内核中集成，旧版的Linux内核则使用ipchains及ipwadm来达成类似的功能，而2014年1月19日起发行的新版Linux内核（3.13+）则使用nftables取代iptables。

Linux内核（2+）：ipwadm；
Linux内核（2）：ipchains；
Linux内核（4、2.6、3.0+）：iptables；
Linux内核（13+）：nftables。

iptables虽然强大但是不可能永远适用于当前的技术发展，任何技术都有其局限性。位于用户空间的iptables，也在被抛弃，RHEL7/CentOS7中已经不再直接使用iptables，而选择firewalld作为他的前端配置工具。

iptables已在Linux内核中集成

IP Tables原理简介

管理工具iptables是与内核网络协议栈中有包过滤功能的5个hook交互来完成工作的，这些内核hook构成netfilter框架。每个进出网络的包在经过协议栈时都会触发这些hook，数据包在内核中的处理路径如下图所示。

数据包在内核中的处理路径

通过iptables下发的规则，最终都会与上图中标注的5个hook点位关联。iptables将这些规则，按照不同的作用划分到不同的表中，按照划分常用的有raw、mangle、filter、nat四张表，即为四表。而关联在5个hook点位的有优先级顺序的规则链，即为五链。这种配置管理逻辑，也就是使用iptables的人都最为熟知的“四表五链”。

下面是iptables常用的四种table类型及其具体作用：

iptables常用的四种table类型

Filter table：是最常用的table之一，用于判断是否允许一个包通过；
Nat table：用于实现数据包的IP地址转换；
Mangle table：用于修改包的IP头；
Raw table：iptables防火墙是有状态的，raw table其唯一目的就是让数据包绕过连接跟踪机制。

表和链的组织逻辑是：不同的表可以作用在不同的链（hook点位）中，在具体链中多种表之间又有优先级顺序，具体如下图所示，红色箭头方向表示各表的优先级顺序依次从高到低排列。

具体链中多种表之间又有优先级顺序

我们通过iptables下发的规则就放置在特定table的特定chain里面，当chain被触发调用的时候，包会依次匹配chain里面的规则，每条规则都有一个匹配部分和一个动作部分。规则的匹配部分指定了一些条件，数据包必须满足这些条件才会和将要执行的动作进行关联。匹配系统非常灵活，还可以通过iptables extension扩展其功能。规则可以匹配协议类型、源目地址、源目端口、源目网段、接收或发送的网卡、协议头、连接状态等条件。这些综合起来，能够组合成非常复杂的规则来区分不同的网络流量。

总结

netfilter包过滤框架和iptables是Linux服务器上大部分防火墙解决方案的基础。其中，netfilter的内核hook与Linux内核协议栈配合得足够紧密，提供了数据包在经过系统时的强大控制能力。而iptables正是基于这些能力提供了一个灵活的、可扩展的、将策略需求转化到内核的方法。理解了这些不同部分是如何联系到一起的，就可以使用iptables创建出可靠的防火墙策略。

IP Tables的应用场景

通过上文可以清楚地了解到，iptables其实是存在于操作系统应用层，作为配置内核中安全框架netfilter的一个客户端。通过iptables可以实现常规防火墙的几乎所有的功能，包括但不限于：

提供基于状态的源目IP地址、源目端口、访问时间等维度的访问控制；
提供双向NAT能力，配合Linux的网络工具可以在网络出口实现链路负载均衡功能；
利用iptables的limit模块，可以实现轻量的DDoS攻击防护；
利用iptables的connlimit模块，可以防护CC攻击；
利用iptables的string模块，对数据包中的内容进行检查，实现报文深度过滤或者数据脱敏功能；
按需管理iptables的日志，可以为不同规则设置不同的日志标识，以便灵活记录数据流日志。

除了作为常规的主机/网络防火墙外，iptables也作为重要的网络组成部分，存在于Docker、K8S、OpenStack的Neutron项目以及众多成熟且应用广泛的开源项目中。

IP Tables的部署实例

首先，简单了解下iptables命令的语法格式，命令格式可分解为如下几部分。

iptables -t <table> <cmd> <pattern> <action>

其中，-t <table>或–table <table>选项用来指定要查看或修改的表（raw、mangle、nat、filter），命令行在不使用-t参数时默认为filter表。<cmd>部分可选择对规则要进行的操作，即增删改查操作，<pattern>为规则的匹配部分，<action>为安全规则的动作部分，对匹配到的数据包做指定的动作。

屏蔽指定IP地址：若发现某个恶意攻击者并确定其IP地址，此时可以使用如下命令将指定IP的数据包丢弃。

BLOCK_THIS_IP=”x.x.x.x”

iptables -A INPUT -i eth0 -p tcp -s “$BLOCK_THIS_IP” -j DROP

此命令行，<cmd>部分使用-A INPUT参数将屏蔽规则插入到filter表（默认）的INPUT链尾。

网卡流量转发：如果在某些场景下使用服务器作为网关，则可能需要两张网卡分别接内网和公网，然后需要将内网的网卡流量转发到连接到公网的网卡中，可以使用iptables实现此功能，命令行如下所示。

iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

端口流量转发：若需要进行端口级别的流量转发，使用iptables同样可以完成，此命令会将2222端口流量转发到22。

iptables -t nat -A PREROUTING -p tcp -d 192.168.1.5 –dport 2222 -j DNAT –to 192.168.1.5:22

使用扩展模块实现WEB流量简单负载：下面将使用nth扩展模块，将80端口流量负载均衡到三台服务器。

iptables -A PREROUTING -i eth0 -p tcp –dport 80 -m state –state NEW -m statistic –mode nth –every 3 –packet 0 -j DNAT –to-destination 192.168.1.11:80

iptables -A PREROUTING -i eth0 -p tcp –dport 80 -m state –state NEW -m statistic –mode nth –every 2 –packet 0 -j DNAT –to-destination 192.168.1.12:80

iptables -A PREROUTING -i eth0 -p tcp –dport 80 -m state –state NEW -m statistic –mode nth –every 1 –packet 0 -j DNAT –to-destination 192.168.1.13:80

在上面的命令行中，采用statistic模块的nth模式来实现轮询的负载均衡效果，参数含义如下：

–every n表示每n个命中就会真正执行一次；
–packet p表示在这条规则的第几次命中时真正执行（0<=p<=n-1）。

需要注意的是，每条规则有独立的计数器，因此-m statistic –mode nth –every 3 –packet 0表示每三个包触发一次动作，在第0次命中时执行动作，在第1次和第2次命中后不触发动作，而是将数据包交给下一条规则处理。同理，第二个包的匹配规则为-m statistic –mode nth –every 2 –packet 0，第三个包的匹配规则为-m statistic –mode nth –every 1 –packet 0。

使用扩展模块实现DDoS流量清洗：下面将使用limit扩展模块，来实现简单的DDoS攻击流量清洗。

iptables -A INPUT -p tcp –dport 80 -m limit –limit 5/minute –limit-burst 100 -j ACCEPT

关于limit限速模块，各参数的含义如下：

–limit n/s表示s时间段内会新签发n个令牌，时间单位有秒、分、时、天；
–limit-burst m表示初始令牌数量以及令牌桶的最大容量。

IP Tables的配置总结

IP Tables的配置

技术手册-RoCEv2 / EVPN-VXLAN / MC-LAG 部署

关注星融元

本文主要描述如何在Asterfusion CX306P-48S（以下简称CX306P）搭建的模拟网络上部署如下解决方案：

RoCEv2：在模拟网络上承载RDMA应用，通过CX306P的PFC和ECN功能，为所承载的RDMA应用构建无损的RoCEv2环境。

BGP EVPN和VXLAN：在模拟网络上承载VXLAN网络，将原本在Open vSwitch上进行的封装、去封装全部从Server端卸载到CX306P内的VTEP上，并且在模拟网络上启动BGP EVPN，自动化地创建VXLAN隧道、传递虚拟网络路由。

MC-LAG：在模拟网络上为服务器创建一个高可靠环境，确保每台服务器都能通过标准LAG双上联到两台CX306P上，这两台CX306P通过MC-LAG被虚拟化成一台高可靠的交换节点。

如上解决方案共用一个物理拓扑，如图1所示：

CX-N的部署拓扑图

部署过程中所涉及到的设备、接口及管理网口的IP地址如下表所示：

设备名称	接口	IP地址
交换机A	管理口	192.168.4.102
交换机B	管理口	192.168.4.105
Server1	管理口	192.168.4.2
Server2	管理口	192.168.4.133
Server3	管理口	192.168.4.150

RoCEv2 / EVPN-VXLAN / MC-LAG部署的硬件与软件环境

部署环境中涉及到的硬件和软件如下表所示：

名称	型号	硬件指标	数量	备注
交换机	CX306P	《参见产品彩页》	2
服务器		1、至少8G内存 2、磁盘不少于500G 3、Server1和Server3的BIOS开启CPU嵌套虚拟化（INTEL：VT-x, AMD:AMD-V）	3	Server1和Server3各需要安装一块Mellanox ConnectX-4网卡（25G）
光模块	10G	SFP+	12
	100G	QSFP28	4
光纤	多模	10G/25G适用	6
	多模	100G适用	2

软件	版本	备注
操作系统	Centos7.6	安装时选择Compute Node 模式，根目录/至少500G
iperf3		可以直接yum install iperf3安装，3台server均需要安装
Mellanox网卡驱动	4.7-3.2.9.0	具体参考《解决方案-Mellanox网卡驱动安装-e-20200211-v1.1》
tcpdump		可以直接yum install tcpdump

RoCEv2的配置部署

逻辑组网与配置思路

RoCEv2的配置部署逻辑组网与配置思路

配置思路：

为交换机A和交换机B配置IP和路由
分别为Server1、Server2、Server3配置IP和路由网关
配置Server1的PFC功能
配置交换机A的ACL打标DSCP功能
使能交换机A和交换机B的QOS功能
先在Server1发送IB流量，观察队列流量
停掉Server1上的流量发送，在Server2发送普通TCP背景流量，观察队列流量
观察ACL规则匹配情况
将Server1和Server2的流量都打起来，观察交换机B的出口拥塞情况
配置交换机A和交换机B的PFC功能
观察测试PFC功能
关闭交换机A和交换机B的PFC功能，配置交换机B的ECN功能
配置服务器ECN相关设置
测试ECN功能

BGP EVPN和VXLAN配置部署

逻辑组网与配置思路

BGP EVPN和VXLAN配置部署逻辑组网与配置思路

配置思路：

配置交换机A和交换机B的HOSTNAME
配置交换机A的EVPN
配置交换机B的EVPN
Server1上创建虚机和VLAN
Server3上创建虚机和VLAN
测试Server1和Server3的连通性
查看交换机A的路由信息
查看交换机B的路由信息

MC-LAG的配置部署思路

逻辑组网与配置思路

MC-LAG的配置部署思路逻辑组网与配置思路

配置思路：

分别为Server1、Server3配置LAG
交换机A创建PortChannel，并添加接口
交换机A创建VLAN，并添加成员
交换B创建PortChannel，并添加接口
交换机B创建VLAN，并添加成员
交换机A配置MC-LAG
交换机B配置MC-LAG
测试链路故障
测试设备故障

全文请注册/登录后获取：https://asterfusion.com/d-20220617/

测试报告-HPC高性能计算测试方案（CX-N系列云交换机）

关注星融元

一位来自金融行业的客户，他们希望可以实时地模拟和响应风险，以实现企业金融风险管理能力的提升。事实上，不管是金融行业还是其他行业，要想加快步伐满足快速数字化世界中的客户需求，就必须能够比标准计算机更快地处理大量数据。高性能计算（HPC)解决方案，正在受到企业们的青睐。

HPC通用架构主要由计算、存储、网络组成，而HPC之所以能够提高计算速度，更多是采用了“并行技术”，使用多个计算机协同工作，采用十台、百台，甚至成千上万台计算机“并行工作”。各个计算机之间需要互相通信，并对任务进行协同处理，这就需要建立一套对时延、带宽等有着严格要求的高速网络。

高带宽、低时延和低资源使用率的RDMA模式（主要体系架构：InfiniBand协议和以太网协议），往往是HPC网络的最佳选择。而星融元CX-N 超低时延交换机（简称CX-N)采用了标准以太网协议和开放软硬件技术，支持无损以太网技术和网络无损防拥塞技术，充分满足用户HPC应用下对网络带宽、时延等的高要求。为验证这一事实，我们选用Mellanox的InfiniBand交换机，与其进行了相同HPC应用下的运行速度的对比测试。

我们在CX-N和Mellanox的MSB7800交换机（简称IB交换机）分别搭建的网络上，进行了E2E转发测试、MPI基准测试和HPC应用测试。结果证明：CX-N 的时延和对方达到了同一个量级，运行速率较对方仅低3%左右，产品性能与对方交换机不相上下，能够满足绝大多数的HPC应用场景。而有必要补充一点的是，星融元更加注重产品成本的把控，星融元HPC解决方案在性价比方面有显著的优势。

HPC场景测试方案全过程：

1、目标与物理网络拓扑

E2E转发测试
测试两款交换机在相同拓扑下E2E（End to End）的转发时延和带宽，本次方案测试点采用Mellanox IB发包工具进行发包，测试过程遍历2~8388608字节。
MPI基准测试
MPI基准测试常用于评估高性能计算性能。本次方案测试点采用OSU Micro-Benchmarks来评估CX-N和IB两款交换机的性能。
HPC应用测试
本次测试方案在每个HPC应用中运行相同任务，并比较CX-N和IB两款交换机的运行速度（时间更短）。

1.1 IB交换机物理拓扑

如上解决方案的IB交换机物理拓扑，如图1所示：

IB交换机物理网络拓扑

图1：IB交换机物理网络拓扑

1.2 CX-N物理拓扑

如上解决方案的CX-N物理拓扑，如图2所示：

CX-N物理网络拓扑

图2：CX-N物理网络拓扑

1.3 管理网口IP规划

部署过程中所涉及到的设备、接口及管理网口的IP地址如下表1所示：

设备管理口列表

表1：设备管理口列表

2、硬件和软件环境

部署环境中涉及到的硬件和软件如表2和表3所示：

硬件环境

表2：硬件环境

软件环境

表3：软件环境

3、测试环境部署

在两台Server服务器上，安装部署HPC三种测试场景所需的基础环境。

补充说明：以”[root@server ~]#”为开头的命令表示两台服务器都要执行。

3.1 E2E转发测试环境部署

在两台Server服务器上安装Mellanox网卡的MLNX_OFED驱动程序，网卡驱动安装完成之后检查网卡及驱动状态，确保网卡可以正常使用。

网卡MLNX_OFED驱动程序安装：

检查网卡及网卡驱动状态：

3.2 MPI基准测试环境部署

在两台Server服务器上安装HPC高性能集群基础环境，安装OSU MPI Benchmarks MPI通信效率测评工具，测试方式分为点对点通信和组网通信两种方式，通过执行各种不同模式的MPI，来测试带宽和时延。

HPC集群高性能基础环境：

OSU MPI Benchamarks工具安装

3.3 HPC应用测试环境部署

在两台Server服务器上安装HPC测试应用。本次方案部署WRF开源气象模拟软件和LAMMPS原子分子并行模拟器来进行数据测试。

WRF安装部署：

WRF全称Weather Research and Forecasting Model, 是一个天气研究与预报模型的软件。

修改Docker网络配置
本方案两台Server服务器WRF部署采用Docker容器部署，需要修改Docker配置文件，将虚拟网桥绑定到Mellanox网卡上，通过直接路由方式实现跨主机Docker容器通信。

WRF应用部署
LAMMPS安装部署：LAMMPS即Large-scale Atomic/Molecular MassivelyParallel Simulator，大规模原子分子并行模拟器，主要用于分子动力学相关的一些计算和模拟工作。

安装GCC-7.3

安装OpenMPI

安装FFTW

安装LAMMPS

随着云计算技术的成熟，HPC正在从应用于大规模科学计算场景，转变为适用各种科学和商业计算场景。《星融元HPC解决方案》将重磅发布，敬请期待！

全文请注册/登录后获取：https://asterfusion.com/d-20220527/

技术手册-BGP路由协议

关注星融元

BGP全称BorderGatewayProtocol，也叫边界网关协议，是一种路径矢量路由协议，最新版本是BGPv4。BGP是互联网上一个核心的去中心化自治路由协议。BGP是最复杂的路由协议，属于应用层协议，其传输层使用TCP，默认端口号是179。BGP是唯一使用TCP作为传输层的路由协议。

BGP的分类介绍

BGP按照运行方式分为eBGP（External/Exterior BGP）和iBGP（Internal/Interior BGP）。

eBGP：运行于不同AS之间的BGP称为eBGP。为了防止AS间产生环路，当BGP设备接收eBGP对等体发送的路由时，会将带有本地AS号的路由丢弃。
iBGP：运行于同一AS内部的BGP称为iBGP。为了防止AS内产生环路，BGP设备不将从iBGP对等体学到的路由通告给其他iBGP对等体，并与所有iBGP对等体建立全连接。为了解决iBGP对等体的连接数量太多的问题，BGP设计了路由反射器和BGP联盟。

应该注意的是，使用内部 BGP 不是使用外部 BGP 的前提条件。自治系统可以从多种内部协议中进行选择，以连接其内部网络上的路由器。

BGP的相关概念

AS(Autonomous sydstem)

自治系统，指在一个（有时是多个）组织管辖下的所有IP网络和路由器的全体，它们对互联网执行共同的路由策略。一个AS是一个独立的整体网络。每个AS有自己唯一的编号。通常一个自治系统将会分配一个全局的唯一的16位号码， ASN范围：1-65535；其中1-64511属于公有ASN，64512-65535属于私有ASN。

AS_Path

路由每通过一个AS范围都会产生一个记录。

BGP报文交互中的角色

BGP报文交互中分为Speaker和Peer两种角色。

Speaker：发送BGP报文的设备称为BGP发言者（Speaker），它接收或产生新的报文信息，并发布（Advertise）给其它BGP Speadker。
Peer：相互交换报文的Speaker之间互称对等体（Peer）。若干相关的对等体可以构成对等体组（Peer Group）。

BGP的路由器号（Router ID）

BGP的Router ID是一个用于标识BGP设备的32位值，通常是IPv4地址的形式，在BGP会话建立时发送的Open报文中携带。对等体之间建立BGP会话时，每个BGP设备都必须有唯一的Router ID，否则对等体之间不能建立BGP连接。
BGP的Router ID在BGP网络中必须是唯一的，可以采用手工配置，也可以让设备自动选取。缺省情况下，BGP选择设备上的Loopback接口的IPv4地址作为BGP的Router ID。如果设备上没有配置Loopback接口，系统会选择接口中最大的IPv4地址作为BGP的Router ID。一旦选出Router ID，除非发生接口地址删除等事件，否则即使配置了更大的地址，也保持原来的Router ID。

BGP的报文

BGP对等体间通过以下5种报文进行交互，其中Keepalive报文为周期性发送，其余报文为触发式发送：
Open报文：用于协商BGP参数，包括版本，AS号，hold time等，然后建立BGP对等体连接。
Update报文：用于在对等体之间交换路由信息。
Notification报文：用于中断BGP连接。
Keepalive报文：用于保持BGP连接。
Route-refresh报文：用于在改变路由策略后请求对等体重新发送路由信息。只有支持路由刷新（Route-refresh）能力的BGP设备会发送和响应此报文。

BGP的3张表

邻居表(adjancy table):保存所有的BGP邻居信息。
BGP表(forwarding database):保存从每一个邻居学到的路由信息。
路由表(routing table):BGP默认不做负载均衡，会从BGP表中选出一条到达各个目标网络最优的路由，放入路由表保存。路由器只需按路由表保存的路由条目转发数据即可。

全文请注册登录后获取：https://asterfusion.com/d-20230427/

资料下载

一文梳理基于优先级的流量控制（PFC）

关注星融元

什么是PFC（基于优先级的流量控制）

丢包对不同协议的影响有所不同，应用会以不同的方式作出响应：一些应用可以容忍这一情况，通过重新发送所丢数据包得以恢复。以太网能够支持这些情况，但有些应用不能容忍任何丢包情况，要求保证端到端传输没有丢包。为了使以太网能够满足应用的无丢包要求，需要制定一种方法来通过以太网提供无损服务。基于优先级的流量控制PFC就产生了。PFC（Priority-based Flow Control，基于优先级的流量控制）功能是一种精细的流量控制机制，在IEEE 802.1Qbb标准文档中的定义是：对传统流控暂停机制的一种增强。PFC是基于优先级为不同的业务来提供不同服务的，可以解决传统以太网流控机制和该需求之间的冲突。

PFC工作原理

PFC是暂停机制的一种增强，PFC允许在一条以太网链路上创建8个虚拟通道，为每条虚拟通道指定一个优先等级并分配专用的资源（如缓存区、队列等等），允许单独暂停和重启其中任意一条虚拟通道而不影响其他虚拟通道流量的传输，保证其它虚拟通道的流量无中断通过。这一方法使网络能够为单个虚拟链路创建无丢包类别的服务，使其能够与同一接口上的其它流量类型共存。

数据中心场景中发生网络拥塞的原因

产生拥塞的原因有很多，在数据中心场景里比较关键也是比较常见的原因有三点：

进行数据中心网络架构设计时，如果采取非对称带宽设计，即上下行链路带宽不一致。也就是说当下联服务器上行发包总速率超过上行链路总带宽时，就会在上行口出现拥塞。
当前数据中心网络多采用Fabric架构，采用ECMP来构建多条等价负载的链路，并HASH选择一条链路来转发，是简单的。但这个过程没有考虑到所选链路本身是否已经拥塞，对于已经产生拥塞的链路来说，会加剧链路的拥塞。
TCP Incast是Many-to-One（多对一）的通信模式，在数据中心云化的大趋势下这种通信模式常常发生，尤其是那些分布式存储和计算应用，包括Hadoop、MapReduce、HDFS等。如图1所示，当一个Parent Server向一组节点发起请求时，集群中的节点会同时收到请求，并且几乎同时相应。所有节点同时向Parent Server发送TCP数据流，使得交换机上连Parent Server的出端口缓存不足，造成拥塞。

TCP Incast多对一通信模式

图1：TCP Incast多对一通信模式

为了实现端到端的无损转发，避免因为交换机中的Buffer缓冲区溢出而引发的数据包丢失，交换机必须引入其他机制，如流量控制，通过对链路上流量的控制，减少对交换机Buffer的压力，来规避丢包的产生。

PFC流量控制的工作机制

一旦出现瞬时拥塞，即某个设备的队列缓存消耗较快，超过一定的阈值，设备即向数据进入的方向发送反压信息，上游设备收到反压信息，会根据反压信息指示停止发送或延迟发送数据，并将数据存储在本地端口buffer，如果本地端口buffer消耗超过阈值，则继续向上反压。直到网络终端设备，从而消除网络节点因拥塞造成的丢包。

如图2所示，交换机Switch-1和Switch-2的连接端口分别创建8个优先级队列，并为每个队列分配相应的buffer，业务报文通过数据流中携带的优先级字段进行标识，buffer大小使得各队列有不同的数据缓存能力。

PFC工作机制

图2：PFC工作机制

Switch-2的第5优先级队列出现拥塞时，本端报文处理方式：

如果Switch-2使能了PFC功能，向上游设备Switch-1发送PFC Pause帧，通知对端设备暂时停止发送第5优先级队列的报文。对端设备在接收到PFC Pause帧后，将暂时停止向本端发送该类报文，暂停时间长短信息由PFC Pause帧所携带。当拥塞仍然存在时，此过程将重复进行，直至拥塞解除；
如果Switch-2没有使能PFC功能，则直接将报文丢弃。

当Switch-1收到PFC Pause帧时，其报文处理方式是：

若Switch-1使能了PFC功能，且尚未暂停发送第5优先级的报文，则暂停发送该优先级的报文，并根据PFC Pause帧中对应的暂停时间启动定时器。当定时器到期后，将恢复相应优先级报文的发送；
若Switch-1使能了PFC功能，且已经暂停发送第5优先级的报文，则根据PFC Pause帧中对应的暂停时间更新对应定时器的到期时间；
若PFC Pause帧中对应的暂停时间为0，则相当于使对应的暂停定时器立即到期，立即恢复相应优先级报文的发送；
若PFC Pause帧中对应的暂停时间不为0，则相当于复位对应的暂停定时器。也就是说，只要本端一直拥塞，则对端会因不断收到PFC Pause帧而持续暂停发送相应优先级的报文；
若Switch-1没有开启相应优先级的PFC功能，则不会暂停发送相应优先级的报文。

PFC的帧格式

Pause帧实际上是一个以太帧，IEEE802.1Qbb中定义了PFC帧的格式，如图3所示：

PFC帧格式

图3：PFC帧格式

Destination MAC Address：目的MAC地址，为01-80-C2-00-00-01；
Source Mac Address：源MAC地址，为本设备MAC地址；
Ethernet type：以太网帧长度或类型域，为88-08，用于标明本帧的类型为MAC控制帧；
Control opcode：MAC控制操作码，PFC Pause帧仅是MAC控制帧的一种，其在MAC控制帧中的操作码为01-01；
Priority enable vector：优先级使能向量，高字节置0，低字节的每个位代表相应的Time[n]是否有效。E[n]代表优先级n，当E[n]为1时，表示Time[n]有效，处理该优先级的数据流，即停止流量发送；当E[n]为0，表示Time[n]无效，忽略该优先级的数据流，即流量不受影响继续发送；
Time：时间，包含Time[0]至time[7]的8个数组单元，每个数组单元为2字节。当E[n]为0时，Time[n]没有意义。当E[n]为1时，Time[n]代表接收站点抑制优先级为n的报文发送的时间，时间的单位为物理层芯片发送512位数据所需要的时间；
Pad（transmit as zero）：预留，传输时为0；
CRC：循环冗余校验。
PFC死锁

PFC死锁，是指当多个交换机之间因微环路等原因同时出现拥塞,各自端口缓存消耗超过阈值，而又相互等待对方释放资源，从而导致所有交换机上的数据流都永久阻塞的一种网络状态。

正常情况下，当一台交换机的端口出现拥塞时，数据进入的方向(即下游设备)将发送PAUSE帧反压，上游设备接收到Pause帧后停止发送数据，如果其本地端口缓存消耗超过阈值，则继续向上游反压。如此一级级反压，直到网络终端服务器在Pause帧中指定Pause Time内暂停发送数据，从而消除网络节点因拥塞造成的丢包。

但在特殊情况下，例如发生链路故障或设备故障时，如图4所示，当4台交换机都同时向对端发送Pause帧，这个时候该拓扑中所有交换机都处于停流状态，由于PFC的反压效应，整个网络或部分网络的吞吐量将变为零。

PFC死锁

图4：PFC死锁

连接SONiC与P4交换芯片的SDE

关注星融元

SONiC作为近几年来在云网络领域最重要的开源网络操作系统，获得了业界足够多的关注，基于P4语言的数据平面可编程技术与架构，也是开放网络生态正在讨论的热点话题之一。随着开源、开放网络的进一步发展，SONiC与P4可编程的全方位融合逐渐出现在产业发展的思考范畴之内，并且逐渐开始了一些初步的尝试。

什么是P4 SDE

自2013年创建以来，网络编程语言P4凭借其优异的抽象能力以及灵活性，将网络的可编程性下压到了数据平面，让数据包的解析和转发流程也能通过编程控制，为实现SDN的终极目标提供了有力支撑。

随着芯片巨头Intel出手收购Barefoot，Tofino系列芯片以及P4生态将获得持续的支持与长久的发展。

Barefoot社区提供的SDE（Software Development Environment）可以用P4语言对数据面进行编程，然后编译好的数据面程序就可以运行在Barefoot Tofino芯片上或是SDE中的模拟芯片上。

Barefoot SDE包括了一系列用于开发P4的组件，包括：

核心组件
Reference Code
测试框架
一系列代码教程示例

其中核心组件包括了：P4语言开发环境（编译器和模拟芯片环境），系统库以及相关驱动；Reference Code包括了：P4源码以及一组层次分明向上提供的API。

Barefoot SDE P4的核心组建展示图

SONiC中的SDE

SONiC使用了Redis中机制来完成系统内各个模块间信息的传递。

在这里我们只需要知道在SONiC中syncd容器是与ASIC通信的唯一通道，控制面的业务进程想将数据下发ASIC时，最终处理流程都是将数据按照SAI标准接口格式写入Redis中的ASIC_DB，syncd容器中的同名主进程syncd订阅ASIC_DB中的相关表项并处理这些下发的数据，调用ASIC SDK对SAI API的实现，并通过ASIC driver下发到ASIC。

其中SDE就包括了ASIC SDK以及运行在Tofino ASIC上的tofino.bin（由P4源码编译生成的二进制程序）。

SDE包括了ASIC SDK以及运行在Tofino ASIC上的tofino.bin

Barefoot SDE在SONiC中表现为deb包的形式，在编译生成SONiC镜像时，由Barefoot SDE编译生成的deb包将会安装在syncd容器中，安装目录如下：

/opt/bfn/install

|– bin

|– include

|– lib

`– share

其中ASIC SDK会以动态链接库的形式放在lib目录下面，被syncd主进程链接；由P4源码编译生成的tofino.bin放在share/switch目录下，运行时通过PCIE通道下发到ASIC中运行。

下面我们以SONiC下发二层MAC表为例来演示SONiC中的P4工作流程。

从SONiC上用命令行配置MAC表到P4转发芯片中的转发流表生效，这一整个流程可以分成下面三个部分进行说明。

第一步：SONiC通过命令行下发一条静态的MAC表，对应数据经过SONiC的业务进程处理，最终将会写入Redis中的ASIC_DB，即1号DB，DB中MAC表的组织形式如下：其中对接口参数的定义与SAI接口定义（如下所示）一致：包括一条fdb_entry以及对应count数量的key-value键值对，由上可知，我们下发了三对键值对，分别为BRIDGE_PORT_ID、TYPE和PACKET_ACTION
第二步：syncd容器中的同名主进程syncd订阅ASIC_DB中的相关表项并调用ASIC SDK对SAI API的实现（如下所示）来处理ASIC_DB中的数据。这一步的处理包括两个部分：参数转换和数据存储。首先做参数转换，将标准SAI接口定义的参数转换成Barefoot SDE中的接口层使用的参数格式，然后将其放入内存结构中进行存储，如下图：于是我们得到最终存储的数据结构如下：数据存储完成之后就会调用P4源码对应的语义接口层（与P4源码中table的语法结构一一对应），即SDE中的API层进入第三步。
第三步：在SDE中的API层对应P4源码的语义结构接口中，将上一步写入内存DB结构里的数据读取出来，将其转义为P4源码定义的table的语法结构，通过ASIC driver下发到ASIC。API层对应P4源码table的语义结构接口如下：

class dmac : {

…

public:

dmac(const switch_object_id_t parent, switch_status_t &status){

…

//读取上一步存储在内存中的数据

status |= switch_store::v_get(

parent, SWITCH_MAC_ENTRY_ATTR_VLAN_HANDLE, vlan_handle);

status |= find_auto_oid(vlan_handle, SWITCH_OBJECT_TYPE_BD, bd_handle);

status |= switch_store::v_get(

parent, SWITCH_MAC_ENTRY_ATTR_MAC_ADDRESS, match_mac);

status |= switch_store::v_get(

parent, SWITCH_MAC_ENTRY_ATTR_PORT_LAG_HANDLE, handle);

//转义为P4源码定义的table的语法结构

//生成流表的match_key

status |= match_key.set_exact(smi_id::F_DMAC_IG_MD_BD, compute_bd(bd_handle));

status |= match_key.set_exact(smi_id::F_DMAC_DST_ADDR, match_mac);

//生成流表的action

action_entry.init_action_data(smi_id::A_DMAC_HIT);

action_entry.set_arg(smi_id::P_DMAC_HIT_PORT_LAG_INDEX,

compute_port_lag_index(handle));

}

switch_status_t create_update() {

//将生成好的流表match_key和action通过ASIC driver下发到ASIC

}

};

在本文示例中用到的P4源码定义的table的语法结构如下：

P4源码定义的table的语法结构

小结

我们通过SONiC命令行下发一条静态的MAC表的数据最终在ASIC中表现出的流表形式为：

下发一条静态的MAC表的数据最终在ASIC中表现出的流表形式

在ASIC进行流量转发时，如果数据包命中这条流表，即BD为03E7（对应VLAN ID为2），dst_mac为00:11:11:11:11:11，该数据包将从06口（对应port为60）出去。

通过本文的描述，希望帮助您对SDE作为SONiC与P4可编程芯片连接的中间组件，进行转发流表下发的数据流动过程有更深的了解。

520 P4可编程表白SDN交换机：我能给你的，比你想象得多！

关注星融元

P4可编程芯片概述

本文中我们以Tofino可编程芯片为例，Tofino芯片包含多个Pipeline，每个Pipeline可以运行不同的查表逻辑（即不同的P4程序），每个Pipeline含12个MAU（Match-Action Unit），出/入Pipeline共享这些MAU。

每一个MAU对应Pipeline流水线中一个Stage阶段，每个Stage支持若干次并发查找，从而可以提升并发查找性能。MAU与MAU之间顺序查找，多级查表或处理可以分布到不同的MAU上，从而可以丰富业务处理逻辑。

图1， P4抽象转发模型

整体设计背景及面临的问题

为了满足交换机高性能处理的需要，设计时，我们采用多个Pipeline同构设计，即所有Pipeline部署相同P4程序，使用相同的处理转发逻辑。

考虑到业务逻辑的复杂性，数据面通常需要定义多个表才可以完成整个业务逻辑，并且流表与流表之间存在依赖关系，有依赖关系的流表会被P4编译器分配到不同的Stage。每个Stage只能访问自己的本地内存，当一张流表没有在运行时使用的时候，它的资源也就白白浪费了。

以下图为例，表21~23依赖于表11的匹配处理结果，如果表11没有处理完，表21~23也无法运行，同理，表31依赖于表21~23的匹配处理结果。

图2，表间依赖导致Stage资源利用率低

因此，在实际编码时，我们会发现虽然用光了所有的Stage资源，但每个Stage资源利用率却很低，极端时，资源利用率甚至不到10%。

优化设计方法

Stage资源利用率低的直接体现就是交换机相应的流表空间的不足。

为了实现交换机流表空间扩充，需要寻找可以提高Stage资源利用率的方法。

通常的调优方法主要包括以下几种：

优化表配置，降低表间耦合度，提升Stage资源利用率。图3，降低表间耦合提升Stage资源利用率
如果实在不能通过流表的设计降低耦合度，就需要深刻理解和调整业务逻辑，一般地做法是将Key或Action依赖改为后继依赖，必要时可以通过牺牲SRAM/TCAM确保低耦合。图4，后继依赖示例
业务逻辑拆分部署。例如，在实际业务场景中，对特定报文执行隧道解封装是常见的需求，如果把整个功能单独放在Ingress Pipeline或单独放在Egress Pipeline，就会增加表间依赖，导致Stage资源利用率低，但是，如果将特定报文的筛选（查表）和处理（修）分别放在Ingress Pipeline和Egress Pipeline，则既能兼顾PHV（PacketHeader Vector）生存周期这一约束性资源的限制，又能提高Stage资源利用率。
巨型表拆解成小表。巨型表会被P4编译器分配到不同的Stage，如下图中的表2和表3是一个巨型表编译后的情况，对于Stage3而言，剩余的资源还可以部署其它拆解后小表，达到资源充分利用的效果。图5，巨型表拆解成小表[/caption]

经过我们大量的实验和调优设计，基于P4可编程的SDN交换机片上SRAM利用率达到74%，片上TCAM利用率达到81%。

下图是优化后Stage资源利用图：

交换机流表扩充

SDN交换机需要根据L2-L4协议头识别所关心的流量，并对这部分流量做过滤和处理。

如下图所示，当收到报文后，适配不同的流表，并根据预定义的匹配动作处理报文。

图7，流表匹配图

其中，报文五元组流表匹配是较为常见的匹配模式，又分为：

五元组精确流表
五元组掩码流表

常规的实现方法是，将报文的五元组定义到同一张流表里来满足基于五元组识别流量的需求。

但SDN交换机对流表规格要求很高，同时也需要不同元组组合。如，

一元组（源IP或目的IP）
二元组（源目的IP）
三元组（源目的IP及协议号）
四元组（源目的IP及源目的端口）
五元组（源目的IP及源目的端口及协议号）等。

基于TCAM可以实现通配五元组规则，就可以通过使用掩码方法忽略部分元组实现不同元组组合的流表，因此，将五元组放在一张流表里是没有问题的。

然而，基于SRAM实现的精确五元组流表受其查表机制（不支持掩码方式）影响，故天然不能满足需要不同元组组合查表的场景。

解决精确五元组流表扩充的方式有两种：

在SRAM上定义不同元组组合的流表：

优点在于编程模型及查找逻辑简单，管理面适配简单。

缺点是固定了6种元组，实际场景中存在6种以外的其他组合规则，灵活性较差。同时，由于不同元组组合的规则共享IP字段，尤其当IPv6时，这导致片上SRAM资源利用率极低，且不能保证规格。

压缩查表的Key：

Tofino芯片提供了Key压缩机制，但这个机制存在误匹配风险。误匹配的概率与流表Key的分布（或哈希后的离散程度）有关，随着已配表项数目的增加尤其在临近满配时，误匹配的概率将急剧提高。

我们在进行精确五元组流表扩充优化设计时，充分结合上述两种方式的优势，同时规避相应的不足，解决思路如下：

将较长Key映射成一个低位宽的Key（防止被编译器优化到不同的MAU），然后用低位宽Key替换IP，并对这些Key做精确（掩码）查找。

这种方法虽然牺牲了一部分SRAM，增加了数据面逻辑的复杂度和管理面适配的复杂度，但优化查表逻辑后可以在保证无误匹配的前提下支持不同五元组组合，使得整体规格在原有数万级别的基础上提升了250%，而不同元组组合规格（中值）提升了200%。

图8，低位宽Key拆解应用

网络加速和业务卸载

“云化”大背景下，处理以隧道为代表的新应用新特性正在变成或已经变成基本需求，这些处理包括隧道封装、解封装、根据隧道内层IP信息进行流量识别和过滤等。

传统处理方式是将这部分流量提交到计算卡（业务卡）上处理，伴随着“云化”流量占比越来越大，本就昂贵的计算资源更加不堪重负。
……

P4可编程的SDN交换机为隧道流量的处理和卸载提供了契机，经过Parser调优设计，可以广泛支持各种隧道和封装协议的识别，如GTP、GRE、MPLS、ERSPAN、VXLAN、IP over IP等，并且可以根据隧道内层IP信息识别和过滤流量。

图9，基于P4可编程交换机实现网络加速和业务卸载

鉴于P4可编程交换机在处理隧道化流量方面有先天优势，这种优势可以转化为解决方案的成本优势；另一方面，如果将释放出计算能力运用到增值业务处理上，这一优势也可以转化为解决方案的增值优势。

除了隧道卸载外，我们还在基于P4的SDN交换机上卸载了诸如关键字匹配过滤、ICMP/ARP代答、报文截短等功能，以实现最大化地释放算力资源的目的。

REST API在SONiC中的实现

关注星融元

REST API 是什么？

REST API是一种面向资源的接口设计，所有的接口设计都是针对资源来设计的。简单理解就是用URI定位资源，用HTTP（GET、POST、DELETE、PUT、PATCH）描述操作。

目前，SONiC有一个原生RESTAPI框架，基于Golang实现，但功能仅有VLAN、VLAN interface、VXLAN tunnel、路由，功能上侧重业务。而星融元（Asterfusion）的REST API早于社区的原生REST API开发，并选择了具有轻量化，性能高的优点的Tornado框架，且一直在沿用。星融元（Asterfusion）REST API可以与SONiC原生REST API同时使用，未来，也将会贡献给社区。

下面我们来详细介绍一下星融元（ Asterfusion ）REST API软件：

星融元（ Asterfusion ）REST API基于Tornado框架开发，通过Nginx实现https方式访问。并在docker容器中运行，开销低，安全性高。同时为了解决RESTAPI在docker容器中不方便做一些系统级的操作如config reload、reboot等问题，我们在HOST上增加了sys-proxy模块，用于REST API直接调用HOST上的命令。

Tornado 是什么？

Tornado是一种 Web 服务器软件的开源版本。Tornado 和主流Web 服务器框架（包括大多数 Python 的框架）有着明显的区别：它是非阻塞式服务器，效率高。

URI说明：https://<SWITCH_IP>[:端口号]/rest/<version>/<resource>
SWITCH_IP：为交换机的管理口IP；
端口号：RESTAPI绑定的https端口号，默认为4430；
版本：V3.0,属于RESTAPI的接口版本
resource是由各功能模块定义，详细说明请联系support@asterfusion.com索取《用户指导-CX系列产品RESTAPI手册》

星融元 REST API 的基本框架

星融元REST API 的软件框图图 1 星融元（Asterfusion） RESTAPI 的软件框图

星融（Asterfusion）REST API运行在一个独立的docker容器中，因为设备web管理组件也运行在其中，所以命名为web-server。

在该容器中，主要包括Ngnix和REST API两大组件。其中Ngnix用于https的代理。

红色虚线中的部分基于Tornado框架实现。其中，service模块为REST API的主入口，它会监听对应端口，注册所有功能模块，并完成整个RESTAPI服务的初始化。

图中Modules就是这些功能模块，包括system、interface、router interface、VLAN等。每个模块包括schema、handler、adapter三部分。

最底层是wrapper层，封装了对数据库的操作。

RESTAPI服务还支持定时任务，比如用于采集接口的各种计数，并计算秒级速率。另外，还提供了一个与HOST进行交互的通道，当RESTAPI服务需要调用系统级的命令时，如reboot，config reload等，会与运行在HOST上的sys-proxy进行通信，用于系统命令的调用。

星融元 REST API 的代码结构

REST API目录下是不同版本的REST API代码目录，Asterfusion REST API已经迭代到了V3版本。

V3目录下，有REST API服务主入口serivce.py和目录common、modules、task、wrapper。

common目录下是一些公共类、函数的实现。modules目录下是所有功能模块的实现，目前已实现的模块有：system、interface、VLAN、MAC、routerinterface、VRF、route、VXLAN、 BGP、EVPN、LAG、MC-LAG、LLDP、ECMP。在每一个module的目录里，都存在__init__.py、handler.py、adapter.py、schema.py这几个文件。

每个模块URI的格式统一在__init__.py里定义，如BGP是：

urls=[[r’/protocols/bgp-neighbors/([0-9a-fA-F.:]*)/?’, handler.BGPNeighborHandler]]

在handler.py中，定义了POST、DELETE、PATCH、GET、PUT方法的顶层实现。每个方法的具体逻辑由adapter.py中的函数实现。schema.py定义了每个模块对数据类型和范围的检查，如果检查不通过，会直接返回错误码。

task目录实现了轮询任务，目前有一个轮询任务是接口实时流量速率的计算。

wrapper是数据库原子级操作的一个封装层，adapter会调用wrapper层的函数。