一、为什么需要无损网络？

随着高性能计算、大数据分析、人工智能以及物联网等技术的飞速发展，集中式存储、分布式存储以及云数据库的普及等原因，业务应用有越来越多的数据需要从网络中获取，这对数据中心网络的交换速度和性能要求越来越高。

传统的TCP/IP软硬件架构及应用存在着网络传输和数据处理的延迟过大、存在多次数据拷贝和中断处理、复杂的TCP/IP协议处理等问题。RDMA（Remote Direct Memory Access，远程直接内存访问）是一种为了解决网络传输中服务器端数据处理延迟而产生的技术。RDMA将用户应用中的数据直接传入服务器的存储区，通过网络将数据从一个系统快速传输到远程系统的存储器中，消除了传输过程中多次数据复制和文本交换的操作，降低了CPU的负载。

简而言之，使用RDMA不需要多次数据拷贝以及中断处理，不经过操作系统内核态，当然也就没有上下文切换，也不需要CPU参与，消耗资源，相较于TCP/IP有巨大的优势，因此广泛应用于HPC高性能计算中。

那RDMA和无损有啥关系？
支持RDMA的网络协议（或者说方法）分为三种：IB(InfiniBand)，iWARP(Internet Wide Area RDMA Protocal)和RoCE(RDMA over Converged Ethernet)。

其中，目前用到的只有IB和RoCE，IB属于原生支持RDMA的方法，但是Roce从字面意思看是RDMA over 以太网（为了省钱，IB太贵），属于非原生支持，后续修改支持的一种方法，因此需要一些条件（需要使用支持Roce的网卡，需要交换机支持无损配置，需要在服务器上配置无损网络等，这些在IB网络中不需要）。介绍完全局概念之后，进入主题，下面主要涉及RoCE网络。
到此处可以明晰RDMA和RoCE以及无损网络之间的关系，RoCE网络的诞生是为了让以太网支持RDMA，而无损网络是为了让RDMA可靠传输，不丢包，至于RDMA为啥会丢包，下面在RoCE v2中会介绍。

RDMA技术：降低数据中心内部网络延迟，提高处理效率。
当前RDMA在以太网上的传输协议是RoCEv2，RoCEv2是基于无连接协议的UDP协议，相比面向连接的TCP协议，UDP协议更加快速、占用CPU资源更少，但其不像TCP协议那样有滑动窗口、确认应答等机制来实现可靠传输，一旦出现丢包，依靠上层应用检查到了再做重传，会大大降低RDMA的传输效率。
所以要想发挥出RDMA真正的性能，突破数据中心大规模分布式系统的网络性能瓶颈，势必要为RDMA搭建一套不丢包的无损网络环境，而实现不丢包的关键就是解决网络拥塞。
（为什么需要无损网络：长期以来，HPC（高性能计算）的RDMA都是在Infiniband集群中使用，数据包丢失在此类群集中很少见，因此RDMA Infiniband传输层（在NIC上实现）的重传机制很简陋，既：go-back-N重传，但是现在RDMA的使用更广泛，在其他网络中，丢包的概率大于Infiniband集群，一旦丢包，使用RDMA的go-back-N重传机制效率非常低，会大大降低RDMA的传输效率，所以要想发挥出RDMA真正的性能，势必要为RDMA搭建一套不丢包的无损网络环境。

RoCE 协议分为两个版本：

· RoCE v1协议：基于以太网承载RDMA，只能部署于二层网络。
· RoCE v2协议：基于UDP/IP协议承载RDMA，可部署于三层网络

RoCE v1协议：
基于以太网承载 RDMA，只能部署于二层网络，它的报文结构是在原有的 IB架构的报文上增加二层以太网的报文头（MAC头），通过 Ethertype 0x8915 标识 RoCE 报文。

RoCE v2协议：
基于 UDP/IP 协议承载 RDMA，可部署于三层网络，它的报文结构是在原有的 IB 架构的报文上增加 UDP 头、IP 头和二层以太网报文头，通过 UDP 目的端口号 4791 标 识RoCE 报文。RoCE v2 支持基于源端口号 hash，采用 ECMP 实现负载分担，提高了网络的利用率。

简而言之，v1是二层网络协议，v2是三层网络协议。

二、无损网络简述

在RoCE网络中，我们需要构建无损以太网用于保证网络传输过程中不丢包。构建无损以太网需支持以下关键特性：
· 数据缓冲区管理和监控：根据流量特点调整端口、队列能够使用的缓冲区大小，并通过命令行方式或gRPC上报缓冲区使用情况。

数据缓冲区大小调整请根据需要在专业人士指导下进行，数据缓冲区监控建议配置。
· （必选）PFC（Priority-based Flow Control，基于优先级的流量控制）：逐跳提供基于优先级的流量控制，能够实现在以太网链路上运行多种类型的流量而互不影响。
· （必选）ECN（Explicit Congestion Notification，显示拥塞通知）：设备发生拥塞时，通过对报文IP头中ECN域的标识，由接收端向发送端发出降低发送速率的CNP（Congestion Notification Packet，拥塞通知报文），实现端到端的拥塞管理，减缓拥塞扩散恶化。
· （建议）DCBX（Data Center Bridging Exchange Protocol，数据中心桥能力交换协议）：使用LLDP自动协商DCB能力参数，包括PFC和ETS等。一般用在接入交换机连接服务器的端口，与服务器网卡进行能力协商。
· （可选）ETS（Enhanced Transmission Selection，增强传输选择）：将流量按服务类型分组，在提供不同流量的最小带宽保证的同时提高链路利用率，保证重要流量的带宽百分比。需要逐跳提供。
H3C推出的还有iNOF无损网络（PFC+AIECN+LLDP）没用到，此处不在展开。

下一代存储项目在使用中仅配置了PFC和ECN必选项，其他部分暂不涉及，下面介绍PFC和ECN。

PFC

（流控发展史：FC(整个链路流控）–>PFC（基于优先级流控）–>PFC+ECN（流控发生前避免拥塞）/PFC+ETS（分配带宽）+ECN）

1. FC(整个链路流控）
   下游发现拥堵，向上游发PAUSE帧
   PFC之前，我们可以先看一下IEEE 802.3X(Flow Control)流控的机制：当接收者没有能力处理接收到的报文时，为了防止报文被丢弃，接收者需要通知报文的发送者暂时停止发送报文。

2.PFC（基于优先级流控）
FC（IEEE 802.3X协议）缺点：一旦链路被暂停，发送方就不能再发送任何数据包，如果是因为某些优先级较低的数据流引发的暂停，结果却让该链路上其他更高优先级的数据流也一起被暂停了，其实是得不偿失的。

如下图中报文解析所示，PFC在基础流控IEEE 802.3X基础上进行扩展，允许在一条以太网链路上创建8个虚拟通道，并为每条虚拟通道指定相应优先级，允许单独暂停和重启其中任意一条虚拟通道，同时允许其它虚拟通道的流量无中断通过。
PFC将流控的粒度从物理（端口）细化到（8个虚拟通道），分别对应Smart NIC硬件上的8个硬件发送队列(这些队列命名为Traffic Class，分别为TC0,TC1,…,TC7)，在RDMA不同的封装协议下，也有不同的映射方式。
带MAC头的pfc报文

下面先把PFC说完，再阐述ECN…
PFC并不是一个完美的产物，PFC有其自己的问题：

死锁（PFCdeadlock）
虽然PFC能够通过给不同队列映射不同优先级来实现基于队列的流控，但同时也引入了新的问题，例如PFC死锁的问题。

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

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

但在特殊情况下，例如发生链路故障或设备故障时，BGP路由重新收敛期间可能会出现短暂环路，会导致出现一个循环的缓冲区依赖。如下图所示，当4台交换机都达到XOFF水线，都同时向对端发送PAUSE帧，这个时候该拓扑中所有交换机都处于停流状态，由于PFC的反压效应，整个网络或部分网络的吞吐量将变为零。
(BGP（Border Gateway Protocol，边界网关协议）是用来连接Internet上的独立系统的路由选择协议。)

即使在无环网络中形成短暂环路时，也可能发生死锁。虽然经过修复短暂环路会很快消失，但它们造成的死锁不是暂时的，即便重启服务器中断流量，死锁也不能自动恢复。

为了解除死锁状态，一方面是要杜绝数据中心里的环路产生，另一方面则可以通过网络设备的死锁检测功能来实现。锐捷RG-S6510-48VS8CQ上的Deadlock检测功能，可以检测到出现Deadlock状态后的一段时间内，忽略收到的PFC帧，同时对buffer中的报文执行转发或丢弃的操作(默认是转发)。

例如，定时器的监控次数可配置设置检测10次，每次10ms内检测是否收到PFC Pause帧。若10次均收到则说明产生Deadlock，对buffer中的报文执行默认操作，之后将设置100ms作为Recover时间后恢复再检测。命令如下：

priority-flow-control deadlock cos-value 5 detect 10 recover 100 //10次检测，100ms recover。
RDMA无损网络中利用PFC流控机制，实现了交换机端口缓存溢出前暂停对端流量，阻止了丢包现象发生，但因为需要一级一级反压，效率较低，所以需要更高效的、端到端的流控能力。

拥塞传播

PauseStorm

由于PFC pause是传递的，所以很容器引起pause frame storm。比如，NIC因为bug导致接收缓冲区填满，NIC会一直对外发送pause frame。需要在NIC端和交换机端使用watchdog机制来防止pause storm。

队头阻塞（HOL Blocking/堵塞问题）

如上图 a)，Flow 1 和 Flow 2 从同一个 Ingress 1 流向不同的 Egress 1 和 2。
图 b)，Egress 1 触发了 PFC Pause，Ingress 1 暂停发送。Flow 2 并不需要经过 Egress 1，却受其影响也被暂停了。

不公平问题(PFCunfairness)

如上图 a)，交换机上两个流入端口有数据流向同一个流出端口：Ingress 1 携带 Flow 1，Ingress 2 携带 Flow 2 和 3。
图 b) 触发了 PFC Pause，Ingress 1 和 2 同时暂停发送。
图 c) Egress 1 队列空闲，通知 Ingress 1 和 2 恢复发送。
图 d) 由于 Ingress 1 和 2 是同时暂停和恢复的，Flow 2 和 3 需要竞争 Ingress 2，导致 Flow 1 始终能够获得比 Flow 2 或 3 更高的带宽，出现了不同 Flow 带宽分配不公平。

关于PFC的话题聊完了，下面聊聊ECN

ECN

当前的RoCE拥塞控制依赖ECN(Explicit Congestion Notification，显式拥塞通知)来运行。ECN最初在RFC 3168中定义，网络设备会在检测到拥塞时，通过在IP头部嵌入一个拥塞指示器和在TCP头部嵌入一个拥塞确认实现。

RoCEv2标准定义了RoCEv2拥塞管理(RCM)。启用了ECN之后，网络设备一旦检测到RoCEv2流量出现了拥塞，会在数据包的IP头部ECN域进行标记。既然在IP头标记那么表明ECN工作在三层，PFC是通过暂停帧反压，工作在二层，与上文中的ECN与PFC对比表格对应。


ECN功能对IP报文头中DS域的最后两个比特位（称为ECN域）进行了如下定义：
· 比特位6用于标识发送端设备是否支持ECN功能，称为ECT位（ECN-Capable Transport）
· 比特位7用于标识报文在传输路径上是否经历过拥塞，称为CE位（Congestion Experienced）

ECN功能工作机制：
(1) 发送端设置ECN域为10，告知路径上的设备及接收端，发送端设备支持ECN功能。
(2) 中间设备发生拥塞并达到门限，拥塞设备将发生拥塞的报文ECN域设置为11，报文正常转发。
(3) 接收端收到ECN置位为11的报文，由传输层发送CNP（Congestion Notification Packet，拥塞通知报文）通知发送端。
(4) 发送端收到CNP报文，对对应的优先级的队列进行降速处理。
(5) 经过一段可配置的时间或者发送一定数量数据，发送端恢复原来的速率。

部署了ECN功能的转发设备对接收到的数据报文进行识别和处理的具体方式如下：
• 当转发设备的报文在出方向进入队列排队，该队列的长度小于下限（也称为ECN门限）时，不对报文进行任何处理，转发设备直接将报文从出接口转发。
• 当转发设备的报文在出方向进入队列排队，该队列的长度大于下限但小于上限时：

¡     如果设备接收到的报文中ECN域取值为00，表示报文发送端不支持ECN功能，转发设备按照丢弃概率计算是否丢弃该接收的报文。
¡     如果设备接收到的报文中ECN域取值为01或者10，表示报文发送端支持ECN功能，将按照丢弃概率来修改部分入方向报文的ECN域为11后继续转发该报文，所有入方向接收到的报文均不丢弃。
¡     如果设备接收到的报文中ECN域取值为11，表示该报文在之前的转发设备上已经出现拥塞，此时转发设备不处理报文，直接将报文从出接口转发。

• 当转发设备的报文在出方向进入队列排队，该队列的长度大于上限时：

¡     如果设备接收到的报文中ECN域取值为00，表示报文发送端不支持ECN功能，转发设备丢弃接收的报文。
¡     如果设备接收到的报文中ECN域取值为01或者10，表示报文发送端支持ECN功能，将按照丢弃概率来修改部分入方向报文的ECN域为11后继续转发该报文，所有入方向接收到的报文均不丢弃。
¡     如果设备接收到的报文中ECN域取值为11，表示该报文在之前的转发设备上已经出现拥塞，此时转发设备不处理报文，直接将报文从出接口转发。

① 发送端发送的IP报文标记支持ECN(10); (ECT=10 or 01，发送端10，接收端01？）
② 交换机在队列拥塞情况下收到该报文，将ECN字段修改为11并发出，网络中其他交换机将透传;
③ 接收端收到ECN为11的报文发现拥塞，正常处理该报文;
④ 接收端产生拥塞通告，每ms级发送一个CNP(Congestion Notification Packets)报文，ECN字段为01，要求报文不能被网络丢弃。接收端对多个被ECN标记为同一个QP的数据包发送一个单个CNP即可(格式规定见下图);–（即对同一个QP的数据发送同一个CNP即可）
⑤ 交换机收到CNP报文后正常转发该报文;
⑥ 发送端收到ECN标记为01的CNP报文解析后对相应的流(对应启用ECN的QP)应用速率限制算法。
简而言之，就是ECN是端到端的玩意，发送端需要表示支持ECN，报文流过交换机时候如果拥塞会给ECN标记为改成11，然后最后流到接收端，接收端会回一个CNP报文给发送端，告诉他少发点。

RoCEv2的CNP包格式如下：

值得注意的是，CNP作为拥塞控制报文，也会存在延迟和丢包，从发送端到接收端经过的每一跳设备、每一条链路都会有一定的延迟，会最终加大发送端接收到CNP的时间，而与此同时交换机端口下的拥塞也会逐步增多，若发送端不能及时降速，仍然可能造成丢包。建议拥塞通告域的规模不要过大，从而避免因为ECN控制报文交互回路的跳数过多，而影响发送端无法及时降速，造成拥塞。
ECN优势：WRED 采用的丢弃报文的动作虽然缓解了拥塞对网络的影响，但将报文从发送端转发到被丢弃位置之间所消耗的网络资源已经被浪费了。因此，在拥塞发生时，如果能将网络的拥塞状况告知发送端，使其主动降低发送速率或减小报文窗口大小，便可以更高效的利用网络资源。
RDMA网络正是通过在网络中部署PFC和ECN功能来实现无损保障。PFC技术让我们可以对链路上RDMA专属队列的流量进行控制，并在交换机入口(Ingress port)出现拥塞时对上游设备流量进行反压。利用ECN技术我们可以实现端到端的拥塞控制，在交换机出口(Egress port)拥塞时，对数据包做ECN标记，并让流量发送端降低发送速率。
从充分发挥网络高性能转发的角度，我们一般建议通过调整ECN和PFC的buffer水线，让ECN快于PFC触发，即网络还是持续全速进行数据转发，让服务器主动降低发包速率。如果还不能解决问题，再通过PFC让上游交换机暂停报文发送，虽然整网吞吐性能降低，但是不会产生丢包。

三、交换机

数据缓冲区

数据缓冲区用来临时存储报文，如图2-1所示，数据缓冲区分为接收缓冲区、发送缓冲区和Headroom缓冲区：
• 接收缓冲区：用来缓存接收的数据。当设备的CPU繁忙时，端口不能立即将收到的报文交给CPU处理，会将数据暂时存储到接收缓冲区；
• 发送缓冲区：用来缓存发送的数据。当网络拥塞时，端口不能立即发送数据，为防止数据丢失，会将数据暂时存储到发送缓冲区；
• Headroom缓冲区：设备优先使用接收缓冲区和发送缓冲区，当这两种数据缓冲区用尽后，设备将使用Headroom数据缓冲区提供额外的报文缓存能力。

缺省情况下，所有队列均分共享区域/固定区域。用户可以手工调整指定队列最多可使用的共享区域/固定区域的大小，其它未配置的队列最多可使用的共享区域/固定区域的大小仍遵循缺省值。

报文优先级与队列映射关系

无损网络的信任模式也有两种，一种是PCP走的是二层，一种是DSCP走的是三层，显然我们用的是三层。
设备在进行报文转发时，将不同优先级的报文放入不同的队列中进行调度转发。报文优先级与队列映射关系与设备配置的优先级映射方式有关。设备支持的优先级映射配置方式包括：优先级信任模式方式、端口优先级方式。
我们设备使用的是优先级信任模式，下面仅说明优先级信任模式。
优先级信任模式方式
配置端口的优先级信任模式后，设备将信任报文自身携带的优先级。通过优先级映射表，使用所信任的报文携带优先级进行优先级映射，根据映射关系完成对报文优先级的修改，以及实现报文在设备内部的调度。端口的优先级信任模式分为：

• dot1p：信任报文自带的802.1p优先级，以此优先级进行优先级映射。
  

• dscp：信任IP报文自带的DSCP优先级，以此优先级进行优先级映射。
  

接口配置PFC功能时，必须配置接口信任报文自带的802.1p优先级或DSCP优先级。接口收到以太网报文，根据优先级信任模式和报文的802.1Q标签状态，设备为不同优先级的报文标记不同的本地优先级（LP），根据本地优先级进行队列调度，具体过程如图3-3所示。

因此交换机设备需要配置DSCP-dot1p、dot1p-dotlp映射表（我们走的是右侧流程）。

PFC配置

配置PFC功能时，必须配置接口信任报文自带的802.1p优先级或DSCP优先级（qos trust { dot1p | dscp }），并且转发路径上所有端口的802.1p优先级与本地优先级映射关系以及DSCP优先级与802.1p优先级映射关系必须一致，否则PFC功能将无法正常工作。
用户可以在系统视图和接口视图下配置以太网接口PFC功能，多次在系统视图和接口视图下配置PFC功能，最后一次配置生效。
不建议在802.1p优先级为0，6或7时配置PFC功能，以免影响设备IRF功能及其它协议正常运行。

开启指定802.1p优先级的PFC功能后，设备会为PFC的各种门限设置一个缺省值，此缺省值在一般的组网环境下是效果较好的参数组合，一般不建议调整。如组网环境或流量背景非常复杂确实需要调整，请参考本节的建议配置方式或咨询专业人员进行调整。


另外，PFC功能与ECN功能同时使用时，需要注意反压帧触发门限值（这里指cell数）需要大于ECN功能配置的high-limit值（queue queue-id [ drop-level drop-level ] low-limit low-limit high-limit high-limit [ discard-probability discard-prob ]），以使ECN功能先生效。

四、无损配置实践

无损配置分为主机侧和交换机侧，主机测包括集群和客户端都要配置无损网络。

主机侧配置

下述命令行需要在每一个支持Roce的网卡上执行

cma_roce_mode -d "${mlx_dev}" -p 1 -m 2  # 设置模式Roce v2

设置 the RDMA-CM ToS to 162 (DSCP 40) (Note: This command is nonpersistent)

cma_roce_tos -d "${mlx_dev}" -t 162

设置 ToS to 162 (DSCP 40) for ALL RoCE traffic (Note: This command is nonpersistent)

echo 162 > /sys/class/infiniband/<mlx-device>/tc/1/traffic_class

开启优先级5通道

mlnx_qos -i "${if_dev}" --pfc 0,0,0,0,0,1,0,0 --trust dscp    echo 6 > /sys/class/net/${if_dev}/ecn/roce_np/cnp_802p_prio # ecn的CNP走优先级6通道

Enable ECN for TCP traffic (Note: This command is nonpersistent)

  sysctl -w net.ipv4.tcp_ecn=1 

下面方法为使用DCBX，我们没有用到DCBX所以不需要
Method 2 - Using LLDP DCBX, and configuration in the switch (Note: This requires LLDP service to be enabled in the switch)

mlxconfig -d /dev/mst/mt4115_pciconf0 -y s LLDP_NB_DCBX_P1=TRUE LLDP_NB_TX_MODE_P1=2 LLDP_NB_RX_MODE_P1=2 LLDP_NB_DCBX_P2=TRUE LLDP_NB_TX_MODE_P2=2 LLDP_NB_RX_MODE_P2=2

交换机端配置

25G服务器配置

下面大致解释下配置的意义避免稀里糊涂的搞错
[H3C]dis current

version 7.1.070, Release 6555P01

sysname H3C

ip vpn-instance 1

telnet server enable # 开启telnet服务
#h3c交换机支持的irf功能 主要和交换机虚拟化有关 不必太关注
irf mac-address persistent timer
irf auto-update enable
undo irf link-delay
irf member 1 priority 1
#log相关
parity-error unrecoverable log enable
#IP转发水平分割
forwarding split-horizon
#IPv4基于带宽的负载分担功能
bandwidth-based-sharing
#mac 地址不遗忘 配不配都行 默认是遗忘的
mac-address timer no-aging
#LLDP 功能开启 二层发现协议
lldp global enable
#PFC池 headroom大小配置
priority-flow-control poolID 0 headroom 9928
#PFC死锁检测相关配置 不用动
priority-flow-control deadlock cos 5 interval 10
priority-flow-control deadlock precision high
#创建的接口组视图
interface range name all interface Twenty-FiveGigE1/0/1 to Twenty-FiveGigE1/0/24 Twenty-FiveGigE1/0/33 to Twenty-FiveGigE1/0/56
interface range name allint interface Twenty-FiveGigE1/0/1 to Twenty-FiveGigE1/0/56
interface range name bond_mym interface Twenty-FiveGigE1/0/7 to Twenty-FiveGigE1/0/9 Twenty-FiveGigE1/0/12 Twenty-FiveGigE1/0/17 to Twenty-FiveGigE1/0/18 Twenty-FiveGigE1/0/49 to Twenty-FiveGigE1/0/50 Twenty-FiveGigE1/0/53 to Twenty-FiveGigE1/0/56
interface range name lipeng interface Twenty-FiveGigE1/0/33 to Twenty-FiveGigE1/0/34 Twenty-FiveGigE1/0/45 to Twenty-FiveGigE1/0/48
interface range name n83 interface Twenty-FiveGigE1/0/13 to Twenty-FiveGigE1/0/16 Twenty-FiveGigE1/0/19 to Twenty-FiveGigE1/0/20
#应用共享缓冲区
buffer apply
#不用管 默认即可
system-working-mode standard
password-recovery enable

vlan 1

vlan 2 to 3

vlan 5 to 10
#映射表 上文提到过 dot1p-lp 代表802.1p 到 local本地的优先级映射
qos map-table dot1p-lp
import 0 export 0
import 1 export 1
import 2 export 2
#dscp优先级到802.1p的映射表 主要关注import 40 export 5， import 48 export 6 默认不显示
qos map-table dscp-dot1p
import 0 export 3
import 1 export 3
import 2 export 3
import 3 export 3
import 4 export 1
import 5 export 3
import 6 export 4
import 7 export 3
import 8 export 3
import 9 export 3
import 10 export 4
import 11 export 3
import 12 export 2
import 13 export 3
import 14 export 3
import 15 export 3
import 16 export 1
import 17 export 3
import 18 export 4
import 19 export 3
import 20 export 1
import 21 export 3
import 22 export 4
import 24 export 1
import 26 export 4
import 32 export 1
import 33 export 3
import 34 export 5
import 35 export 6
import 36 export 3
import 37 export 3
import 39 export 5
import 41 export 3
import 42 export 3
import 43 export 3
import 44 export 3
import 45 export 3
import 46 export 3
import 47 export 3
import 49 export 3
import 50 export 3
import 51 export 3
import 52 export 3
import 53 export 3
import 54 export 3
import 55 export 3
import 56 export 3
import 57 export 3
import 58 export 3
import 59 export 3
import 60 export 3
import 61 export 3
import 62 export 3
import 63 export 3
#WRED表 队列在low到high limit之间概率丢包 high limit之上全丢 low limit以下不丢（主要是TCP中拥塞避免的一种方法），但是开启ECN之后操作有所不同，开启ECN后将丢包操作转换为ECN拥塞报文转发操作
qos wred queue table QOS-EGRESS-25G-PORT
queue 0 drop-level 0 low-limit 2500 high-limit 10000 discard-probability 20
queue 0 drop-level 1 low-limit 2500 high-limit 10000 discard-probability 20
queue 0 drop-level 2 low-limit 2500 high-limit 10000 discard-probability 20
queue 1 drop-level 0 low-limit 2500 high-limit 10000 discard-probability 20
queue 1 drop-level 1 low-limit 2500 high-limit 10000 discard-probability 20
queue 1 drop-level 2 low-limit 2500 high-limit 10000 discard-probability 20
queue 2 drop-level 0 low-limit 2500 high-limit 10000 discard-probability 20
queue 2 drop-level 1 low-limit 2500 high-limit 10000 discard-probability 20
queue 2 drop-level 2 low-limit 2500 high-limit 10000 discard-probability 20
queue 3 drop-level 0 low-limit 2500 high-limit 10000 discard-probability 20
queue 3 drop-level 1 low-limit 2500 high-limit 10000 discard-probability 20
queue 3 drop-level 2 low-limit 2500 high-limit 10000 discard-probability 20
queue 4 drop-level 0 low-limit 2500 high-limit 10000 discard-probability 20
queue 4 drop-level 1 low-limit 2500 high-limit 10000 discard-probability 20
queue 4 drop-level 2 low-limit 2500 high-limit 10000 discard-probability 20
queue 5 drop-level 0 low-limit 200 high-limit 500 discard-probability 20
queue 5 drop-level 1 low-limit 200 high-limit 500 discard-probability 20
queue 5 drop-level 2 low-limit 200 high-limit 500 discard-probability 20
queue 5 weighting-constant 0
queue 5 ecn
queue 6 drop-level 0 low-limit 400 high-limit 1625 discard-probability 20
queue 6 drop-level 1 low-limit 400 high-limit 1625 discard-probability 20
queue 6 drop-level 2 low-limit 400 high-limit 1625 discard-probability 20
queue 6 ecn
queue 7 drop-level 0 low-limit 37999 high-limit 38000 discard-probability 20
queue 7 drop-level 1 low-limit 37999 high-limit 38000 discard-probability 20
queue 7 drop-level 2 low-limit 37999 high-limit 38000 discard-probability 20
#生成树协议启动，主要为了避免环路风险，广播风暴以及mac表不稳定的问题
stp global enable

接口内配置

[H3C-if-range-n83]dis this

interface Twenty-FiveGigE1/0/13
port link-mode bridge # 二层接口
link-delay up 2 # link延迟 不用管 不配也行
priority-flow-control deadlock enable # PFC死锁检测
buffer egress cell queue 5 shared ratio 100 # 共享缓冲区 出口队列五可以使用率100%
buffer egress cell queue 6 shared ratio 100 # 共享缓冲区 出口队列六可以使用率100%

priority-flow-control enable # PFC启动
priority-flow-control no-drop dot1p 5 # PFC队列5
flow-interval 5 # 接口数据统计时间间隔
#PFC相关参数配置 上文已经描述过
priority-flow-control dot1p 5 headroom 491
priority-flow-control dot1p 5 reserved-buffer 20
priority-flow-control dot1p 5 ingress-buffer dynamic 5
priority-flow-control dot1p 5 ingress-threshold-offset 12
#qos 信任策略 采用三层的dscp
qos trust dscp
qos wfq byte-count # 开始wfq 加权平均队列
#下面是7个队列 其中byte-count代表每次轮询可发送的字节数
qos wfq af1 group 1 byte-count 2
qos wfq af2 group 1 byte-count 3
qos wfq af3 group 1 byte-count 15
qos wfq af4 group 1 byte-count 20
qos wfq ef group 1 byte-count 60
qos wfq cs6 group sp # 严格队列
qos wfq cs7 group sp # 严格队列
#应用WRED qos表
qos wred apply QOS-EGRESS-25G-PORT
#流量整形
qos gts queue 6 cir 12500000 cbs 16000000

return
[H3C-if-range-n83]

五、无损网络trouble shooting

服务器端

通过服务器端配置那些命令检查下是否命令生效，因为服务器端配置的都是临时性的，重启会失效，因为那些参数是存在内存的。
检查RoCE网络，方法参考下面链接
RDMA/ROCE SOLUTIONS
RoCE Debug Flow for Linux (nvidia.com)

服务器端查看CNP包，需要先启动mst start ，具体方法参考下述链接
HowTo Read CNP Counters on Mellanox adapters (nvidia.com)
服务器端给压力，拉高线程跑1M IO，25G交换机带宽基本在2G-3G多

常用命令：
Ibdev2netdev
ibv_devinfo
show_gids

交换机端

一般交换机端看有无丢包
dis packet-drop summary
Packets dropped due to insufficient data buffer. Input dropped: 0 Output dropped: 0 # 这一行无丢包
Packets of ECN marked: 4635708831
#ECN有触发
当然可能交换机上其他集群如果无损有问题会影响判断，可以选择查看端口的丢包情况如下：
dis packet-drop int tw 1/0/19
如果有丢包则基本可以认为无损配置有问题。

PFC功能与ECN功能同时使用时，需要注意反压帧触发门限值（这里指cell数）需要大于ECN功能配置的high-limit值

常用命令：
display qos map-table 显示映射表
display buffer usage interface verbose # 查看buffer使用情况
dis counters inbound interface 端口入口包统计
dis counters outbound interface 端口出口包统计
dis qos queue-statistics int tw1/0/13 outbound 查看接口queue出队列丢包情况
d c r i i 统计上个采样周期端口入口速率
d c r o i 统计上个采样周期端口出口速率
dis priority-flow-control interface # 查看PFC端口信息
dis int tw 1/0/13 # 查看端口数据（可以看到入口/出口发包，单播广播多播，速率）

probe # 进入诊断视图
debug port mapping slot 1 # 查看port map
bcm slot 1 chip 0 show/c/xe3 # 查看底层端口信息
[H3C-probe]bcm slot 1 chip 0 a # 查看芯片型号
Attach: Unit 0 (BCM56873_A0): attached (current unit)

六、参考资料

H3C无损网络最佳实践
https://www.h3c.com/cn/Service/Document_Software/Document_Center/Home/Public/00-Public/Configure/Practice/H3C-PT_Long/#_Toc100133849

【RDMA】无损网络和PFC（基于优先级的流量控制）|ECN
https://blog.51cto.com/liangchaoxi/4046404

详谈RDMA技术原理和三种实现方式
https://www.51cto.com/article/648715.html
H3C UIS超融合产品RDMA全无损网络配置指导
https://www.h3c.com/cn/Service/Document_Software/Document_Center/Home/H3Cloud/00-Public/Configure/Operation_Manual/H3C_UIS_RDMA-Long/?CHID=778602#_Toc119000541

LOSSLESS ROCE CONFIGURATION FOR LINUX DRIVERS IN DSCP-BASED QOS MODE
Lossless RoCE Configuration for Linux Drivers in DSCP-Based QoS Mode (nvidia.com)

RDMA/ROCE SOLUTIONS
RoCE Debug Flow for Linux (nvidia.com)

HOWTO READ CNP COUNTERS ON MELLANOX ADAPTERS
HowTo Read CNP Counters on Mellanox adapters (nvidia.com)

UNDERSTANDING QOS CONFIGURATION FOR ROCE
Understanding QoS Configuration for RoCE (nvidia.com)

HOWTO AUTO-CONFIG PFC AND ETS ON CONNECTX-4 VIA LLDP DCBX
https://enterprise-support.nvidia.com/s/article/howto-auto-config-pfc-and-ets-on-connectx-4-via-lldp-dcbx

08-ACL和QoS命令参考
https://www.h3c.com/cn/d_201906/1203033_30005_0.htm#_Toc12266340