- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
手册下载
RDMA技术专题
S6805系列Release 66xx
S6825系列Release 66xx
S6850系列Release 655x，Release 66xx
S9850系列Release 655x，Release 66xx
S9820-64H交换机Release 655x，Release 66xx
S9820-8C交换机 Release 66xx
资料版本：6W100-20220425
|
Copyright © 2022 新华三技术有限公司 版权所有，保留一切权利。 非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部， 并不得以任何形式传播。本文档中的信息可能变动，恕不另行通知。 |
|
目 录
4.3.3 配置数据缓冲区中Headroom缓冲区的监控功能
8.2.2 利用grpc_dialout.proto文件生成C++代码
8.2.3 利用grpc_dialout.proto生成的代码进行二次开发
随着高性能计算、大数据分析、人工智能以及物联网等技术的飞速发展，集中式存储、分布式存储以及云数据库的普及等原因，业务应用有越来越多的数据需要从网络中获取，这对数据中心网络的交换速度和性能要求越来越高。
传统的TCP/IP软硬件架构及应用存在着网络传输和数据处理的延迟过大、存在多次数据拷贝和中断处理、复杂的TCP/IP协议处理等问题。RDMA（Remote Direct Memory Access，远程直接内存访问）是一种为了解决网络传输中服务器端数据处理延迟而产生的技术。RDMA将用户应用中的数据直接传入服务器的存储区，通过网络将数据从一个系统快速传输到远程系统的存储器中，消除了传输过程中多次数据复制和文本交换的操作，降低了CPU的负载。
图1-1 传统TCP/IP数据传输过程
图1-2 RDMA数据传输过程
RDMA技术实现了在网络传输过程中两个节点之间数据缓冲区数据的直接传递，在本节点可以直接将数据通过网络传送到远程节点的内存中，绕过操作系统内的多次内存拷贝，相比于传统的网络传输，RDMA无需操作系统和TCP/IP协议的介入，可以轻易的实现超低延时的数据处理、超高吞吐量传输，不需要远程节点CPU等资源的介入，不必因为数据的处理和迁移耗费过多的资源。
RDMA技术主要包括：
· IB（InfiniBand）：基于InfiniBand架构的RDMA技术，由IBTA（InfiniBand Trade Association）提出。搭建基于IB技术的RDMA网络需要专用的IB网卡和IB交换机。
· iWARP（Internet Wide Area RDMA Protocal）：基于TCP/IP协议的RDMA技术，由IETF标准定义。iWARP支持在标准以太网基础设施上使用RDMA技术，但服务器需要使用支持iWARP的网卡。
· RoCE（RDMA over Converged Ethernet）：基于以太网的RDMA技术，也是由IBTA提出。RoCE支持在标准以太网基础设施上使用RDMA技术，但是需要交换机支持无损以太网传输，需要服务器使用RoCE网卡。
H3C以太网交换机能够支持iWARP，其中部分系列（具体系列请咨询市场技术人员或查看产品配套资料）支持无损以太网传输的关键技术，能够支持RoCE。
InfiniBand是一种基于InfiniBand架构的RDMA技术，它提供了一种基于通道的点对点消息队列转发模型，每个应用都可通过创建的虚拟通道直接获取本应用的数据消息，无需其他操作系统及协议栈的介入。InfiniBand架构的应用层采用了RDMA技术，可以提供远程节点间RDMA读写访问，完全卸载CPU工作负载；网络传输采用了高带宽的传输；链路层设置特定的重传机制保证服务质量，不需要数据缓冲。
InfiniBand必须运行在InfiniBand网络环境下，必须使用IB交换机及IB网卡才可实现。
图2-1 InfiniBand架构
InfiniBand技术具有以下特点：
· 应用层采用RDMA技术，降低了在主机侧数据处理的延迟。
· 消息转发控制由子网管理器完成，没有类似以太网复杂的协议交互计算。
· 链路层通过重传机制保证服务质量，不需要数据缓冲，无丢包。
· 具有低延迟、高带宽、低处理开销的特点。
iWARP是基于以太网和TCP/IP协议的RDMA技术，可以运行在标准的以太网基础设施上。
iWARP由MPA、DDP、RDMAP三层子协议组成：
· RDMAP层协议负责RDMA读、写操作和RDMA消息的转换，并将RDMA消息转发到DDP层。
· DDP层协议负责将过长的RDMA消息分片分装成DDP数据包继续转发到MPA层。
· MPA层在DDP数据段的固定标识位置增加转发后向标识、数据报文的长度以及CRC校验数据等字段构成MPA数据段交由TCP传输。
iWARP从以下几个方面降低了主机侧网络负载：
· TCP/IP处理流程从CPU卸载到RDMA网卡处理，降低了CPU负载。
· 消除内存拷贝：应用程序可以直接将数据传输到对端应用程序内存中，显著降低CPU负载。
· 减少应用程序上、下文切换：应用程序可以绕过操作系统，直接在用户空间对RDMA网卡下发命令，降低了开销，显著降低了应用程序上、下文切换造成的延迟。
由于TCP协议能够提供流量控制和拥塞管理，因此iWARP不需要以太网支持无损传输，仅通过普通以太网交换机和iWARP网卡即可实现，因此能够在广域网上应用，具有较好的扩展性。
RoCE技术支持在以太网上承载IB协议，实现RDMA over Ethernet。RoCE与InfiniBand技术有相同的软件应用层及传输控制层，仅网络层及以太网链路层存在差异。
图2-2 RoCE架构
RoCE协议分为两个版本：
· RoCE v1协议：基于以太网承载RDMA，只能部署于二层网络，它的报文结构是在原有的IB架构的报文上增加二层以太网的报文头，通过Ethertype 0x8915标识RoCE报文。
· RoCE v2协议：基于UDP/IP协议承载RDMA，可部署于三层网络，它的报文结构是在原有的IB架构的报文上增加UDP头、IP头和二层以太网报文头，通过UDP目的端口号4791标识RoCE报文。RoCE v2支持基于源端口号hash，采用ECMP实现负载分担，提高了网络的利用率。
RoCE使得基于以太网的数据传输能够：
· 提高数据传输吞吐量。
· 减少网络延时。
· 降低CPU负载。
RoCE技术可通过普通以太网交换机实现，但服务器需要支持RoCE网卡，网络侧需要支持无损以太网络，这是由于IB的丢包处理机制中，任意一个报文的丢失都会造成大量的重传，严重影响数据传输性能。
在RoCE网络中，我们需要构建无损以太网用于保证网络传输过程中不丢包。构建无损以太网需支持以下关键特性：
· 数据缓冲区管理和监控：根据流量特点调整端口、队列能够使用的缓冲区大小，并通过命令行方式或gRPC上报缓冲区使用情况。
数据缓冲区大小调整请根据需要在专业人士指导下进行，数据缓冲区监控建议配置。
· （必选）PFC（Priority-based Flow Control，基于优先级的流量控制）：逐跳提供基于优先级的流量控制，能够实现在以太网链路上运行多种类型的流量而互不影响。
· （必选）ECN（Explicit Congestion Notification，显示拥塞通知）：设备发生拥塞时，通过对报文IP头中ECN域的标识，由接收端向发送端发出降低发送速率的CNP（Congestion Notification Packet，拥塞通知报文），实现端到端的拥塞管理，减缓拥塞扩散恶化。
在RoCE环境中，PFC与ECN需要同时使用，以在无丢包情况下带宽得到保证。二者的功能对比如表3-1所示。
表3-1 PFC与ECN对比
|
比较项目 |
PFC |
ECN |
|
网络位置 |
二层 |
网络层及传输层 |
|
作用范围 |
点到点 |
端到端 |
|
是否需要全网支持 |
是 |
否 |
|
被控制对象 |
网络中上一节点，如果服务器网卡支持PFC，PFC对网卡也能生效 |
发送主机 |
|
报文缓存位置 |
中间网络节点及发送端 |
发送端 |
|
受影响的流量 |
网络设备中8个转发队列中某个队列的所有流量 |
发生拥塞应用的连接 |
|
响应速度 |
快 |
慢 |
数据缓冲区用来临时存储报文，如图4-1所示，数据缓冲区分为接收缓冲区、发送缓冲区和Headroom缓冲区：
· 接收缓冲区：用来缓存接收的数据。当设备的CPU繁忙时，端口不能立即将收到的报文交给CPU处理，会将数据暂时存储到接收缓冲区；
· 发送缓冲区：用来缓存发送的数据。当网络拥塞时，端口不能立即发送数据，为防止数据丢失，会将数据暂时存储到发送缓冲区；
· Headroom缓冲区：设备优先使用接收缓冲区和发送缓冲区，当这两种数据缓冲区用尽后，设备将使用Headroom数据缓冲区提供额外的报文缓存能力。
发送数据缓冲区和接收数据缓冲区在缓存数据时，都会同时用到cell资源。cell资源用来存储数据包的内容，端口会根据报文的实际大小占用相应大小的cell资源。比如一个cell资源是208字节，当发送的报文是128字节时，端口会给它分配一个cell资源，当发送的报文是300字节时，端口会给它分配两个cell资源。
S9820-64H交换机一个cell资源是208字节，S9820-8C交换机一个cell资源是254字节，S6805、S6825、S6850、S9850系列交换机一个cell资源是256字节。
cell资源分为共享区域和固定区域。
· 固定区域是按队列划分的，每个队列又按端口均分，如图4-2所示。如果设备CPU繁忙或网络发生拥塞，设备在接收或发送报文时，会根据一定的策略将报文分发到相应的队列。如果该端口的该队列缓冲区满，则放到共享区域中的相应队列；如果共享区域中该队列满，则将报文丢弃。在固定缓冲区中，系统会根据用户的配置给队列预留指定大小的空间，即便该队列没有报文存储需求，其他队列也不能抢占。给队列预留的空间均分给每个端口的，即使某端口的某队列没有报文存储需求，其他端口也不能抢占。
· 共享区域只按队列划分，不再按端口均分，如图4-2所示。系统会根据用户配置以及实际需要收发报文的数量决定每个队列实际可占用的缓冲区的大小。如果某个队列没有报文存储需求，则其他队列会抢占该队列的配额。对于某个队列的缓冲区，所有端口接收或发送的报文采用抢占的方式，先到先得，如果资源耗尽，则后到达的报文将被丢弃。
· Headroom区域：当端口PFC功能生效并触发PFC反压帧门限后，本端设备发送PFC PAUSE帧到对端设备让对端停止流量发送的过程中，已经在途的这部分流量的缓存空间，设备需要这些缓冲空间来保证PFC流程的不丢包。
· 共享区域和Headroom区域还可以按照服务池（Service Pool）进行划分，如图4-2所示。服务池是针对不同应用服务划分出来的独立空间。
¡ 对于共享区域：用户可以配置指定服务池可使用共享区域的大小，以及将指定队列映射到指定服务池，此时该队列只能抢占该服务池的资源，不会影响其它服务池的工作。缺省情况下，所有共享缓冲区均属于Service Pool 0。
¡ 对于Headroom区域：目前S6805、S6825、S6850&S9850、S9820-64H、S9820-8C产品仅支持Service Pool 0。
缺省情况下，所有队列均分共享区域/固定区域。用户可以手工调整指定队列最多可使用的共享区域/固定区域的大小，其它未配置的队列最多可使用的共享区域/固定区域的大小仍遵循缺省值。
本文主要介绍队列的数据缓冲区管理，更多数据缓冲区管理功能请参见“ACL和QoS配置指导”和“ACL和QoS命令参考”中的“数据缓冲区”。
对于数据缓冲区相关配置，接口下的配置的优先级高于系统下的配置，即如果针对某队列在接口视图及系统视图下均做了配置，则接口视图下的配置生效。
(1) 进入系统视图。
system-view
(2) 配置队列最多可使用的固定区域的大小。
（系统视图）
buffer egress [ slot slot-number ] cell queue queue-id guaranteed ratio ratio
缺省情况下，所有队列最多可使用的固定区域比例均为13%。
（接口视图）
a. 进入以太网接口视图。
interface interface-type interface-number
b. 配置队列最多可使用的固定区域的大小。
buffer egress cell queue queue-id guaranteed ratio ratio
缺省情况下，接口视图下所有队列最多可使用固定区域的大小为系统视图下对应命令的配置值。
c. 退回系统视图。
quit
(3) 配置队列最多可使用的共享区域的大小。
（系统视图）
buffer egress [ slot slot-number ] cell queue queue-id shared { ratio ratio | size }
缺省情况下，每个队列最多可使用的共享区域比例均为20%。
S6805、S6825、S6850、S9850系列交换机、S9820-64H交换机、S9820-8C交换机Release 6616及以上版本支持size参数。
（接口视图）
a. 进入以太网接口视图。
interface interface-type interface-number
b. 配置队列最多可使用的共享区域的大小。
buffer egress cell queue queue-id shared { ratio ratio | size }
缺省情况下，接口视图下所有队列最多可使用共享区域的大小为系统视图下对应命令的配置值。
S6805、S6825、S6850、S9850系列交换机、S9820-64H交换机、S9820-8C交换机Release 6616及以上版本支持size参数。
c. 退回系统视图。
quit
(4) 配置服务池最多可使用的共享区域的大小。
buffer { egress | ingress } slot slot-number cell service-pool sp-id shared ratio ratio
缺省情况下，服务池0可使用共享区域的大小为100%。
(5) 应用数据缓冲区分配规则。
buffer apply
仅系统视图的配置需要执行本命令以使配置生效。
(6) 进入以太网接口视图。
interface interface-type interface-number
(7) 配置队列与服务池的映射关系。
buffer { egress | ingress } queue queue-id map-to service-pool sp-id
缺省情况下，所有队列均映射到服务池0。
(8) 退回系统视图。
quit
(9) 配置Headroom最大可用的cell资源。
priority-flow-control poolID pool-number headroom headroom-number
缺省情况下：对于S6805&S6825&S6850&S9850系列交换机和S9820-8C交换机，Headroom最大可用的cell资源为12288；对于S9820-64H系列交换机，Headroom最大可用的cell资源为28672。
S6805、S6825、S6850&S9850、S9820-64H、S9820-8C产品仅支持Service Pool 0。
本命令的更多详细信息请参考对应产品二层技术-以太网交换配置指导和二层技术-以太网交换命令参考中的“以太网接口”。
用户可以设置接口使用数据缓冲区的门限值，设备通过该值来判断接口当前是否处于超量使用缓冲区的状态。当接口上某一队列中需要处理的报文增多，造成该接口对数据缓冲区的使用比例超过设定的门限值时，系统会为该队列增加一次超量使用缓冲区的计数，以此监控数据缓冲区的使用情况。
(1) 进入系统视图。
system-view
(2) 配置接口的数据缓冲区使用门限值。
buffer usage threshold slot slot-number ratio ratio
缺省情况下，接口的数据缓冲区使用门限值为100。
(1) 进入系统视图。
system-view
(2) 配置接口队列接收或发送数据缓冲区使用门限值。
（系统视图）
buffer { egress | ingress } usage threshold slot slot-number queue queue-id ratio ratio
缺省情况下，全局所有接口下每个队列的接收或发送数据缓冲区使用门限值均为100%。
（接口视图）
a. 进入以太网接口视图。
interface interface-type interface-number
b. 配置接口队列接收或发送数据缓冲区使用门限值。
buffer { egress | ingress } usage threshold queue queue-id ratio ratio
缺省情况下，接口视图下所有队列的使用门限值为系统视图下对应命令的配置值。
c. 退回系统视图。
quit
(3) 配置服务池使用率的告警门限值功能。
buffer { egress | ingress } usage threshold service-pool sp-id slot slot-number ratio ratio
缺省情况下，服务池使用率的告警门限值为100%。
(4) （可选）配置接收或发送数据缓冲区超门限告警发送周期。
buffer threshold alarm { egress | ingress } interval interval
缺省情况下，数据缓冲区超门限告警发送周期为5秒。
(5) 开启接收或发送数据缓冲区超门限告警功能。
buffer threshold alarm { egress | ingress } enable
缺省情况下，数据缓冲区超门限告警功能处于关闭状态。
(1) 进入系统视图。
system-view
(2) 配置接口Headroom缓冲区的使用门限值。
（系统视图）
buffer usage threshold headroom slot slot-number ratio ratio
缺省情况下，全局所有接口下每个队列的Headroom缓冲区使用门限值均为100%。
（接口视图）
a. 进入以太网接口视图。
interface interface-type interface-number
b. 配置接口Headroom缓冲区的使用门限值。
buffer usage threshold headroom queue queue-id ratio ratio
缺省情况下，接口视图下所有队列的Headroom缓冲区使用门限值为系统视图下对应命令的配置值。
c. 退回系统视图。
quit
(3) （可选）配置Headroom缓冲区超门限告警发送周期。
buffer threshold alarm headroom interval interval
缺省情况下，Headroom缓冲区超门限告警发送周期为5秒。
(4) 开启Headroom缓冲区超门限告警功能。
buffer threshold alarm headroom enable
缺省情况下，Headroom缓冲区超门限告警功能处于关闭状态。
(1) 进入系统视图。
system-view
(2) （可选）配置数据缓冲区丢包告警发送周期。
buffer packet-drop alarm interval interval
缺省情况下，数据缓冲区丢包告警发送周期为5秒。
(3) 开启数据缓冲区丢包告警功能。
buffer packet-drop alarm enable
缺省情况下，数据缓冲区丢包告警功能处于关闭状态。
|
显示内容 |
显示命令 |
|
· 队列的数据缓冲区使用门限值 · 队列超量使用缓冲区的计数 |
display buffer usage interface [ interface-type [ interface-number ] ] |
|
· 入、出方向队列已使用的数据缓冲区大小 · 入、出方向队列可用的数据缓冲区大小 · 入、出方向队列缓存使用率 · 入、出方向队列缓存使用历史峰值 |
display buffer usage interface [ interface-type [ interface-number ] ] verbose |
|
· 入方向队列已使用Headroom缓冲区的cell资源个数 · 入方向队列Headroom缓冲区使用历史峰值 · 入、出方向队列Headroom缓冲区可用量 |
display buffer usage interface [ interface-type [ interface-number ] ] verbose |
|
· 出方向队列转发报文字节数报文个数 · 出方向队列丢弃报文字节数报文个数 |
display qos queue-statistics interface [ interface-type interface-number ] outbound |
# 显示接口Twenty-FiveGigE1/0/1的数据缓冲区简要使用统计信息。
<Sysname> display buffer usage interface twenty-fivegige 1/0/1
Interface QueueID Total Used Threshold(%) Violations
--------------------------------------------------------------------------------
WGE1/0/1 0 6692352 0 70 0
1 6692352 0 70 0
2 6692352 0 70 0
3 6692352 0 70 0
4 6692352 0 70 0
5 6692352 0 70 0
6 6692352 0 70 0
7 6692352 0 70 0
表4-1 display buffer usage interface命令显示信息描述表
|
字段 |
描述 |
|
Interface |
接口名称 |
|
QueueID |
队列编号 |
|
Total |
队列可用的数据缓冲区大小，单位为Byte |
|
Used |
队列已使用的数据缓冲区大小，单位为Byte |
|
Threshold(%) |
队列的数据缓冲区使用门限值，该值与队列所在接口的缓冲区使用门限值保持一致 |
|
Violations |
队列超量使用缓冲区的计数，表示队列使用缓冲区超过设定门限值的次数 该字段仅在设备重启时，才会清零后重新计数 |
# 显示接口Twenty-FiveGigE1/0/1的数据缓冲区详细使用统计信息。
<Sysname> display buffer usage interface twenty-fivegige 1/0/1 verbose
Twenty-FiveGigE1/0/1
Ingress:
QueueID: 0
Total: 127974 Used: 0 Threshold(%): 70
//Total：队列可用的数据缓冲区大小，单位为cell资源个数
//Used：队列已使用的数据缓冲区大小，单位为cell资源个数
//Threshold(%)：队列的数据缓冲区使用门限值，该值与队列所在接口的缓冲区使用门限值保持一致
Violations: 0 Shared: 0 Headroom: 0
//Violations：队列超量使用缓冲区的计数，表示队列使用缓冲区超过设定门限值的次数，该字段在设备重启时，会清//零重新计数
//Shared：队列已使用共享数据缓冲区的cell资源个数
//Headroom：队列已使用Headroom缓冲区的cell资源个数
XoffThres: 127968 IsDynamic: 0
Used(%): 0 Free: 127968 UsedPeak: 0
//XoffThres：反压帧触发门限值，显示的数值为具体配置的cell资源个数
//IsDynamic：0表示反压帧触发门限为静态，1表示反压帧触发门限为动态
//Used(%)：队列缓存使用率
//Free：队列缓存可用量，单位为cell资源个数
//UsedPeak：队列缓存使用历史峰值，即本次执行display命令与上次执行display命令之间这段时间的峰值，单位为cell资源个数
HeadroomUsed(%): 0 HeadroomFree: 0 HeadroomPeak: 0
//HeadroomUsed(%)：入方向队列HEADROOM使用率
//HeadroomFree：入方向队列HEADROOM可用量，单位为cell资源个数
//HeadroomPeak：入方向队列HEADROOM使用历史峰值，即本次执行display命令与上次执行display命令之间这//段时间的峰值，单位为cell资源个数
......其它 Queue的显示信息略......
Egress:
QueueID: 0
Total: 116070 Used: 0 Threshold(%): 70
//Total：队列可用的数据缓冲区大小，单位为cell资源个数
//Used：队列已使用的数据缓冲区大小，单位为cell资源个数
//Threshold(%)：队列的数据缓冲区使用门限值，该值与队列所在接口的缓冲区使用门限值保持一致
Violations: 0 TailDropThres: 116070 IsDynamic: 1
//Violations：队列超量使用缓冲区的计数，表示队列使用缓冲区超过设定门限值的次数，该字段在设备重启时，会清//零重新计数
//TailDropThres：尾丢弃门限值，该值由buffer queue shared命令配置的占用比计算得到
//IsDynamic：该字段取值为1，表示尾丢弃门限为动态
DeadlockCount: 0 DeadlockRecover: 0
Used(%): 0 Free: 116070 UsedPeak: 0
//DeadlockCount：出方向队列DEADLOCK发生次数
//DeadlockRecover：出方向队列DEADLOCK恢复次数
//Used(%)：队列缓存使用率
//Free：队列缓存可用量，单位为cell资源个数
//UsedPeak：队列缓存使用历史峰值，即本次执行display命令与上次执行display命令之间这段时间的峰值，单位为cell资源个数
......其它 Queue的显示信息略......
# 显示接口Twenty-FiveGigE1/0/1的队列出方向统计信息。
<Sysname> display qos queue-statistics interface twenty-fivegige 1/0/1 outbound
Interface: Twenty-FiveGigE1/0/1
Direction: outbound
Forwarded: 0 packets, 0 bytes
Dropped: 0 packets, 0 bytes
Queue 0
Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
......其它Queue的显示信息略......
表4-2 display qos queue-statistics interface outbound命令显示信息描述表
|
字段 |
描述 |
|
Interface |
端口队列统计的端口 |
|
Direction |
端口队列统计的方向 |
|
Forwarded |
转发的数据包数目和字节数 |
|
Dropped |
丢弃的数据包数目和字节数 |
|
Queue 0、Queue 1、Queue 2、Queue 3、Queue 4、Queue 5、Queue 6、Queue 7 |
某端口队列统计信息 |
|
Current queue length |
当前队列长度 |
gRPC（Google Remote Procedure Call，Google远程过程调用）是Google发布的基于HTTP 2.0传输层协议承载的高性能开源软件框架。它提供了支持多种编程语言的、对网络设备进行配置和管理的方法。通信双方可以基于该软件框架进行二次开发。
gRPC协议栈分层如表4-3所示。
表4-3 gRPC协议栈分层模型
|
分层 |
说明 |
|
内容层 |
业务模块的数据 通信双方需要了解彼此的数据模型，才能正确交互信息 |
|
Protocol Buffers编码层 |
gRPC通过Protocol Buffers编码格式承载数据 |
|
gRPC层 |
远程过程调用，定义了远程过程调用的协议交互格式 |
|
HTTP 2.0层 |
gRPC承载在HTTP 2.0协议上 |
|
TCP层 |
TCP连接提供面向连接的、可靠的、顺序的数据链路 |
Protocol Buffers编码是Google的一种数据交换的格式，它与JSON、XML类似，独立于语言，独立于平台，提供了一种灵活、高效、自动序列化结构数据的机制。
Protocol Buffers编码通过proto文件描述数据结构，用户可以利用Protoc等工具软件根据proto文件自动生成其他编程语言（例如Java、C++、Python）代码，然后基于这些生成的代码进行二次开发，以实现gRPC设备对接。
如图4-3所示，gRPC网络采用客户端/服务器模型，使用HTTP 2.0协议传输报文。
图4-3 gRPC网络架构
gRPC网络的工作机制如下：
(1) 服务器通过监听指定服务端口来等待客户端的连接请求。
(2) 用户通过执行客户端程序登录到服务器。
(3) 客户端调用.proto文件提供的gRPC方法发送请求消息。
(4) 服务器回复应答消息。
H3C设备支持作为gRPC服务器或者gRPC客户端。
在RDMA应用中，设备作为客户端向采集器上报RDMA相关监控信息。本章仅介绍设备作为gRPC客户端上报缓存使用情况的相关配置。
配置传感器采样路径时，具体包括以下2种类型：
· 事件触发：传感器组的数据采样没有固定周期，仅由事件触发。关于事件触发类型的采样路径，请参见对应模块的《NETCONF XML API Event Reference》手册。
· 周期采样：传感器组以固定的时间间隔来进行数据采样。关于周期采样类型的采样路径，请参见对应模块的除《NETCONF XML API Event Reference》之外的其他NETCONF XML API手册。
对于缓存监控，请参见“Comware BufferMonitor NETCONF XML API Event Reference”和“Comware V7 BufferMonitor GRPC API Reference”。该文件随版本发布流程发布，请注意获取最新版本。
配置gRPC上报事件触发类型信息之前需开启对应功能的监控告警功能，数据缓冲区支持的监控告警功能请参见“数据缓冲区监控配置”。
a. 进入系统视图。
system-view
b. 开启gRPC功能。
grpc enable
缺省情况下，gRPC功能处于关闭状态。
设备通过传感器完成数据的采集。
a. 进入系统视图。
system-view
b. 进入Telemetry视图。
telemetry
c. 创建传感器组，并进入传感器组视图。
sensor-group group-name
d. 配置采样路径。
sensor path path
多次执行本命令可配置多个采样路径。
对于缓存监控，可以执行sensor path buffermonitor/?命令查看支持的采样路径，具体采样路径支持的采样信息请参见“Comware V7 BufferMonitor GRPC API Reference”和“Comware BufferMonitor NETCONF XML API Event Reference”中的对应表。
例如：
- buffermonitor/bufferusages：上报缓存使用情况。
- buffermonitor/headroomusages：上报headroom使用情况。
- buffermonitor/portqueoverrunevent：上报某端口某队列入方向、出方向、或headroom缓存使用告警。
- buffermonitor/portquedropevent：上报某端口某队列入方向或出方向丢弃报文统计计数。
采集器用于接收网络设备推送的采样数据。设备上需要建立目标组并在目标组中配置正确的采集器地址信息，才能和采集器通信。
a. 进入系统视图。
system-view
b. 进入Telemetry视图。
telemetry
c. 创建目标组，并进入目标组视图。
destination-group group-name
d. 配置采集器的地址和相关参数。
（IPv4网络）
ipv4-address ipv4-address [ port port-number ] [ vpn-instance vpn-instance-name ]
（IPv6网络）
ipv6-address ipv6-address [ port port-number ] [ vpn-instance vpn-instance-name ]
多次执行本命令可配置多个采集器。
完成传感器组和目标组的配置后，需要创建订阅并将二者关联，设备才能和目标组中的采集器建立gRPC连接，从而将订阅报文发送给采集器。
a. 进入系统视图。
system-view
b. 进入Telemetry视图。
telemetry
c. 创建订阅，并进入订阅视图。
subscription subscription-name
d. 配置关联传感器组。
sensor-group group-name [ sample-interval interval ]
当传感器组中的采样路径为事件触发类型时，请不要配置sample-interval参数，否则该采样路径不生效；当采样路径为周期采样类型时，必须配置sample-interval参数才会采样和推送数据。
e. 配置关联目标组。
destination-group group-name
具体开发方式请参考8.2 gRPC对接软件开发。
数据缓冲区更多详细信息请参考对应产品“ACL和QoS配置指导”和“ACL和QoS命令参考”中的“数据缓冲区”。
gRPC更多详细信息请参考对应产品“Telemetry配置指导”和“Telemetry命令参考”中的“gRPC”。
PFC是构建无损以太网的必选手段之一，能够逐跳提供基于优先级的流量控制。设备在进行报文转发时，根据报文的优先级进入对应映射关系的队列中进行调度转发。当某一优先级报文发送速率超过接收速率，导致接收方可用数据缓冲空间不足时，设备通过PFC PAUSE帧反馈给上一跳设备，上一跳设备收到PAUSE帧报文后停止发送本优先级报文，直到再收到PFC XON帧或经过一定的老化时间后才能恢复流量发送。通过使用PFC功能，使得某种类型的流量拥塞不会影响其他类型流量的正常转发，从而达到同一链路上不同类型的报文互不影响。
图5-1 PFC功能PAUSE帧产生示意图
如图5-1所示，当Device B的端口1发生拥塞时，PAUSE帧产生过程如下：
(1) Device B的端口1收到来自Device A的报文后，MMU（Memory Manage Unit，存储器管理单元）会为该报文分配cell资源，当设备的PFC功能处于开启状态时，会根据报文中的dot1p优先级统计占用的cell资源。
cell资源：用来存储数据包的内容，端口会根据报文的实际大小占用相应大小的cell资源。比如一个cell资源是208字节，当发送的报文是128字节时，端口会给它分配一个cell资源，当发送的报文是300字节时，端口会给它分配两个cell资源。
(2) 当Device B端口1的某个优先级的报文占用的cell资源统计计数达到设置的门限后，再收到新的该优先级报文后，端口1会发送对应优先级的PFC PAUSE帧给Device A。
(3) Device A收到该优先级的PFC PAUSE帧后停止发送对应优先级的报文，对该优先级的报文进行缓存，如果触发了缓存门限，则也向其上游设备发送PFC PAUSE帧，如图5-2所示。
设备在进行报文转发时，将不同优先级的报文放入不同的队列中进行调度转发。报文优先级与队列映射关系与设备配置的优先级映射方式有关。设备支持的优先级映射配置方式包括：优先级信任模式方式、端口优先级方式。
· 优先级信任模式方式
配置端口的优先级信任模式后，设备将信任报文自身携带的优先级。通过优先级映射表，使用所信任的报文携带优先级进行优先级映射，根据映射关系完成对报文优先级的修改，以及实现报文在设备内部的调度。端口的优先级信任模式分为：
- dot1p：信任报文自带的802.1p优先级，以此优先级进行优先级映射。
- dscp：信任IP报文自带的DSCP优先级，以此优先级进行优先级映射。
· 端口优先级方式
未配置端口的优先级信任模式时，设备会将端口优先级作为报文自身的优先级。通过优先级映射表，对报文进行映射。用户可以配置端口优先级，通过优先级映射，使不同端口收到的报文进入对应的队列，以此实现对不同端口收到报文的差异化调度。
接口配置PFC功能时，必须配置接口信任报文自带的802.1p优先级或DSCP优先级。接口收到以太网报文，根据优先级信任模式和报文的802.1Q标签状态，设备为不同优先级的报文标记不同的本地优先级（LP），根据本地优先级进行队列调度，具体过程如图5-3所示。
本文仅介绍接口信任报文自带的802.1p优先级或DSCP优先级的情况下，报文优先级到本地优先级的映射情况，关于端口采用端口优先级时的映射情况和报文丢弃时参考的丢弃优先级请参考产品配置指导。
配置PFC功能时，必须配置接口信任报文自带的802.1p优先级或DSCP优先级（qos trust { dot1p | dscp }），并且转发路径上所有端口的802.1p优先级与本地优先级映射关系以及DSCP优先级与802.1p优先级映射关系必须一致，否则PFC功能将无法正常工作。
用户可以在系统视图和接口视图下配置以太网接口PFC功能，多次在系统视图和接口视图下配置PFC功能，最后一次配置生效。
不建议在802.1p优先级为0，6或7时配置PFC功能，以免影响设备IRF功能及其它协议正常运行。
如果设备处于IRF模式时，IRF物理端口也需要开启PFC功能。IRF相关内容的详细介绍，请参见“虚拟化技术配置指导”中的“IRF”。
在Overlay网络中，需要配置qos trust tunnel-dot1p命令，PFC功能才能生效。有关Overlay网络的详细介绍，请参见“VXLAN配置指导”中的“VXLAN”。有关qos trust tunnel-dot1p命令的详细介绍，请参见“ACL和QoS命令参考”中的“QoS/优先级映射”。
为了避免报文在传输过程中因拥塞而发生丢包，请在报文流经的所有端口上都进行相同的PFC功能配置。
当设备的PFC功能出现紧急故障时，用户不用逐个接口去关闭PFC功能，可以通过命令行一键关闭所有接口的PFC功能。当故障恢复后，可以通过命令行一键开启所有接口的PFC功能。
(1) 进入系统视图。
system-view
(2) 开启所有以太网接口的PFC功能。
priority-flow-control enable { receive | send }
缺省情况下，所有以太网接口的PFC功能处于关闭状态。
(3) 开启所有以太网接口的指定802.1p优先级的PFC功能。
priority-flow-control no-drop dot1p dot1p-list
缺省情况下，所有以太网接口的802.1p优先级的PFC功能都处于关闭状态。
(1) 进入系统视图。
system-view
(2) 进入以太网接口视图。
interface interface-type interface-number
(3) 配置端口优先级信任模式为dot1p或dscp。
qos trust { dot1p | dscp }
(4) 配置PFC功能的开启模式。
priority-flow-control enable { receive | send }
缺省情况下，PFC功能处于关闭状态。
(5) 开启指定802.1p优先级的PFC功能。
priority-flow-control no-drop dot1p dot1p-list
缺省情况下，所有802.1p优先级的PFC功能都处于关闭状态。
(6) （可选）配置PFC PAUSE帧的暂停时间。
priority-flow-control pause-time time-vale
缺省情况下，PFC PAUSE帧的暂停时间为65535，单位为当前端口发送512bit数据需要的时间。
通过配置PFC缓存门限可以有效解决因缓冲空间不足和入流量队列数量过大，导致发送数据缓冲区尾丢弃等问题。
图5-4 PFC缓存门限示意图
PFC目前提供以下门限设置：
· Headroom缓存门限（如图5-4中的headroom）：Headroom存储空间中某802.1p优先级报文的最大使用cell资源。当达到使用的cell资源后，该接口会丢弃收到的报文。
· 反压帧触发门限（如图5-4中的XOFF）：Shared存储空间中某802.1p优先级报文在该存储空间使用cell资源上限。达到上限后，会触发PFC功能发送PAUSE帧。反压帧触发门限又分为动态反压帧触发门限和静态反压帧触发门限：
¡ 动态反压帧触发门限：设置某802.1p优先级报文触发PFC PAUSE帧的可用cell资源的百分比。
¡ 静态反压帧触发门限：设置某802.1p优先级报文触发PFC PAUSE帧的可用cell资源门限为一个固定值。
可以通过display buffer usage interface verbose命令的“XoffThres”和“IsDynamic”字段查看当前的反压帧触发门限和类型。
· 反压帧停止门限与触发门限间的偏移量（如图5-4中的ingress-threshold-offset）：当某802.1p优先级报文使用的cell资源减小了一个固定值时，停止发送PFC PAUSE帧，使对端设备恢复流量发送。
· PFC预留门限（如图5-4中的reserved-buffer）：Guaranteed存储空间中为某802.1p优先级报文预留的cell资源。
· Headroom最大可用的cell资源：配置Headroom存储空间某缓存池（目前仅支持pool 0）cell资源的大小。
开启指定802.1p优先级的PFC功能后，设备会为PFC的各种门限设置一个缺省值，此缺省值在一般的组网环境下是效果较好的参数组合，一般不建议调整。如组网环境或流量背景非常复杂确实需要调整，请咨询专业人员进行调整。
(1) 进入系统视图。
system-view
(2) 配置Headroom最大可用的cell资源。
priority-flow-control poolID pool-number headroom headroom-number
缺省情况下：对于S6805&S6825&S6850&S9850系列交换机和S9820-8C交换机，Headroom最大可用的cell资源为12288；对于S9820-64H系列交换机，Headroom最大可用的cell资源为28672。
(3) 进入以太网接口视图。
interface interface-type interface-number
(4) 配置Headroom缓存门限。
priority-flow-control dot1p dot1p-list headroom headroom-number
(5) 配置反压帧触发门限。
¡ 配置动态反压帧触发门限。
priority-flow-control dot1p dot1p-list ingress-buffer dynamic ratio
¡ 配置静态反压帧触发门限。
priority-flow-control dot1p dot1p-list ingress-buffer static threshold
对于S6850&S9850系列交换机R6616以下版本，静态反压帧触发门限为512。对于S6850&S9850系列交换机R6616及以上版本，未配置静态反压帧触发门限。
S6805、S6825、S9820-64H和S9820-8C交换机缺省情况下未配置静态反压帧触发门限。
(6) 配置反压帧停止门限与触发门限间的偏移量。
priority-flow-control dot1p dot1p-list ingress-threshold-offset offset-number
当指定802.1p优先级报文使用的cell资源比触发门限减小offset-number时，停止发送PFC PAUSE帧，使对端设备恢复流量发送。
(7) 配置PFC预留门限。
priority-flow-control dot1p dot1p-list reserved-buffer reserved-number
表5-1 PFC门限缺省配置（适用于R6616及以上版本）
|
产品系列 |
PFC门限（右） 接口类型（下） |
Headroom缓存门限 |
动态反压帧触发门限 |
反压帧停止门限与触发门限间的偏移量 |
PFC预留门限 |
|
S6805&S6825&S6850&S9850 |
1GE/10GE |
100 |
5 |
12 |
17 |
|
25GE |
125 |
5 |
12 |
17 |
|
|
40GE |
200 |
5 |
12 |
17 |
|
|
100GE |
491 |
5 |
12 |
17 |
|
|
S9820-8C |
100GE |
491 |
5 |
12 |
20 |
|
400GE |
1000 |
5 |
12 |
20 |
|
|
S9820-64H |
25GE |
125 |
5 |
12 |
20 |
|
100GE |
491 |
5 |
12 |
20 |
表5-2 PFC门限缺省配置（适用于R6616以下版本）
|
产品系列 |
PFC门限（右） 接口类型（下） |
Headroom缓存门限 |
动态反压帧触发门限 |
反压帧停止门限与触发门限间的偏移量 |
PFC预留门限 |
|
S6805&S6825&S6850&S9850&S9820-8C |
所有接口 |
8192 |
未配置 |
48 |
6 |
|
S9820-64H |
所有接口 |
9984 |
未配置 |
48 |
8 |
正常情况下，当设备的端口出现拥塞并触发PFC的反压帧触发门限（XOFF）时，设备将向数据进入的方向发送PAUSE帧反压，上游设备接收到PAUSE帧后停止发送数据，如果其本地端口缓存消耗超过阈值，则继续向上游反压。如此逐级向上反压，直到发出流量的服务器收到PAUSE帧后，在PAUSE帧中指定的Pause Time内暂停发送数据，从源头上减少流量的发送，从而消除网络节点因拥塞造成的丢包。
但在特殊情况下，例如发生链路故障或设备故障时，路由重新收敛期间可能会出现短暂环路。此时，设备间反复发送和接收PFC帧，报文无法转发，接口缓冲区的cell资源一直被占用无法释放，设备进入PFC死锁状态。
如图5-5所示：Server 1到Server 2的流量转发路径原本为Server1—〉Device C—〉Device A—〉Device D—〉Server 2；假设Device D到Server 2的链路发生故障，在路由重新收敛的过程中形成一条Server1—〉Device C—〉Device A—〉Device D—〉Device B—--〉Device C--〉 Server 2的转发路径，使设备间形成一条Device C—〉Device A—〉Device D—〉Device B—--〉Device C的环路；此时如果Device C连接Server 2的端口发生拥塞，设备向上游发送PFC Pause帧，PFC Pause帧将在上述环路中循环发送，使环路上所有设备都停止流量发送，等待对端释放资源，进入PFC死锁状态。
图5-5 PFC死锁产生示意图
设备处于PFC死锁状态后，采用关闭PFC功能或者忽略接收到的PFC PAUSE帧（PFC XOFF，表示停止流量发送）的方式，同时对buffer中的报文执行转发或者丢弃动作，就可以规避掉PFC死锁这种极端现象。设备的PFC死锁检测间隔可以达到毫秒级别，可以最大程度的降低PFC死锁带来的影响。
本功能中指定的Cos优先级对应的802.1p优先级必须开启了PFC功能。Cos与802.1p优先级的对应关系请通过display qos map-table dot1p-lp命令查看。
PFC死锁检测功能的配置任务如下：
死锁检测功能的恢复方式为自动恢复时，设备检测到PFC死锁后，在延迟时间内设备将忽略接收到的PFC PAUSE帧并关闭PFC死锁检测功能，以便报文能够正常转发。
设备解除PFC死锁后，需要恢复PFC死锁检测功能（同时恢复PFC功能）。
指定优先级报文死锁检测周期的具体时间等于priority-flow-control deadlock cos interval命令配置的interval值*priority-flow-control deadlock precision命令配置的时间精度值。例如配置priority-flow-control deadlock cos 5 interval 10表示Cos优先级为5的报文的死锁检测周期为10个精度单位，同时priority-flow-control deadlock precision命令配置精度为高精度（代表10毫秒），则Cos优先级为5的报文的死锁检测周期时间为10*10毫秒=100毫秒。
(1) 进入系统视图。
system-view
(2) 配置PFC死锁检测定时器的精度。
priority-flow-control deadlock precision { high | normal | low }
缺省情况下，PFC死锁检测定时器的精度为普通精度。
high：表示使用高精度的PFC死锁检测定时器，高精度所代表的时间为10 ms；
normal：表示使用普通精度的PFC死锁检测定时器，普通精度所代表的时间为100 ms；
low：表示使用低精度的PFC死锁检测定时器，暂不支持配置。
(3) 配置PFC死锁检测的周期。
priority-flow-control deadlock cos cos-value interval interval [ pause-recover ]
缺省情况下，未配置PFC死锁检测的周期。
interval interval：PFC死锁检测周期，取值范围为1～15。
pause-recover：根据接口收到PFC PAUSE帧的情况自动恢复PFC功能和PFC死锁检测功能。当检测周期达到时，如果接口处于PFC死锁状态，且接口仍能收到PFC PAUSE帧，则认为接口故障未恢复，接口继续处于PFC死锁状态；当检测周期达到时，如果接口处于PFC死锁状态，但接口未收到PFC PAUSE帧，则认为接口故障已恢复，自动恢复接口的PFC功能和PFC死锁检测功能。不指定该参数时，表示在检测周期到达时不根据接口收到PFC PAUSE帧的情况自动恢复PFC功能和PFC死锁检测功能。仅Release 6616及以上版本支持本参数。
设备检测到PFC死锁后，在自动恢复延迟时间内，设备将忽略接收到的PFC XOFF帧并关闭PFC死锁检测功能，以便报文能够正常转发。
指定优先级报文死锁检测自动恢复的延迟时间等于 = 100ms + delay-interval * 100ms。例如配置priority-flow-control deadlock auto-recover cos 5 delay 10表示Cos优先级为5的报文的死锁检测自动恢复延迟周期为10，则Cos优先级为5的报文的死锁检测自动恢复延迟时间为100毫秒 + 10*100毫秒=1100毫秒。
自动恢复的延迟周期仅对自动恢复方式生效，手工方式下需要用户手动执行priority-flow-control deadlock recover命令恢复。
priority-flow-control deadlock auto-recover action命令配置的延迟时间内对报文的处理动作同时对自动恢复方式和手动恢复方式生效。
(1) 进入系统视图。
system-view
(2) 配置PFC死锁检测自动恢复的延迟周期。
priority-flow-control deadlock auto-recover cos cos-value delay delay-interval
缺省情况下，未配置PFC死锁检测的恢复周期。
delay delay-time：PFC死锁检测自动恢复的延迟周期，取值范围为1～15。
(3) 配置设备在恢复PFC死锁检测的延迟时间内对报文的处理动作。
priority-flow-control deadlock auto-recover action { discard | forwarding }
缺省情况下，设备在恢复PFC死锁检测的延迟时间内转发收到的数据报文。
设备解除PFC死锁后，需要恢复PFC死锁检测功能，同时恢复正常的PFC功能。死锁检测功能的恢复方式分为自动恢复和手工恢复。
通常情况下，使用自动恢复方式即可。当环路无法消除，设备频繁处于PFC死锁状态时，可以使用手工恢复方式，待排除故障后执行priority-flow-control deadlock recover命令恢复PFC死锁检测功能。
通过配置在指定周期内发生PFC死锁的上限次数，可以判断设备是否频繁处于PFC死锁状态。需要注意的是：设备检测到指定时间内PFC死锁次数超限后，会自动关闭PFC功能，请尽快排除网络故障，然后执行undo priority-flow-control deadlock threshold命令恢复PFC功能。
(1) 进入系统视图。
system-view
(2) 配置在指定周期内发生PFC死锁的上限次数。
priority-flow-control deadlock threshold cos cos-value period period count count
缺省情况下，未配置指定周期内发生PFC死锁的上限次数。
period period：发生PFC死锁次数的检测周期，单位为秒，取值范围为1～60。
count count：指定周期内发生PFC死锁的上限次数，单位为次数，取值范围为1～500。
本命令配置的检测周期需要大于PFC死锁检测周期时间（priority-flow-control deadlock cos interval命令配置的interval值*priority-flow-control deadlock precision命令配置的时间精度值），以便确认设备是否频繁处于PFC死锁状态。
(3) 进入以太网接口视图。
interface interface-type interface-number
(4) 配置PFC死锁检测功能的恢复方式。
priority-flow-control deadlock recover-mode { auto | manual }
缺省情况下，PFC死锁检测功能恢复方式为自动恢复方式。
(5) （可选）手工恢复PFC死锁检测功能。
priority-flow-control deadlock recover
配置PFC死锁检测功能的恢复方式为manual时，只有配置本命令才能恢复PFC死锁检测功能。
(1) 进入系统视图。
system-view
(2) 进入以太网接口视图。
interface interface-type interface-number
(3) 开启PFC死锁检测功能。
priority-flow-control deadlock enable
缺省情况下，PFC死锁检测功能处于关闭状态。
|
日志内容 |
PFC Deadlock Recovery Event Begin.Port is [STRING]. |
|
参数解释 |
$1：以太网接口编号 |
|
日志等级 |
4 |
|
举例 |
DRVPLAT/4/DrvDebug: PFC Deadlock Recovery Event Begin.Port is HGE1/1/3. |
|
日志说明 |
设备检测到以太网接口发生PFC死锁事件。 |
|
处理建议 |
无 |
|
日志内容 |
PFC Deadlock Recovery Event End.Port is [STRING]. |
|
参数解释 |
$1：以太网接口编号 |
|
日志等级 |
4 |
|
举例 |
DRVPLAT/4/DrvDebug PFC Deadlock Recovery Event End.Port is HGE1/1/3. |
|
日志说明 |
设备以太网接口的PFC死锁状态解锁完毕 |
|
处理建议 |
无 |
|
日志内容 |
Please recover PFC deadlock.Port is [STRING]. |
|
参数解释 |
$1：以太网接口编号 |
|
日志等级 |
4 |
|
举例 |
DRVPLAT/4/DrvDebug Please recover PFC deadlock.Port is HGE1/1/3 |
|
日志说明 |
设备检测到PFC死锁未恢复完成，不允许配置其余命令行更改检测状态 |
|
处理建议 |
无 |
|
日志内容 |
PFC deadlock limit has been checked, Ifname: [STRING], Cos: [UINT32], times: [UINT32]. |
|
参数解释 |
$1：以太网接口编号 $2：Cos优先级值（与802.1p优先级的对应关系可以通过display qos map-table dot1p-lp命令查看） $3：PFC死锁次数 |
|
日志等级 |
4 |
|
举例 |
DRVPLAT/4/DrvDebug PFC deadlock limit has been checked, Ifname: HGE1/1/3, Cos: 5, times: 10. |
|
日志说明 |
设备在配置的时间间隔内检测到优先级为5的报文发生超过上限次数的PFC死锁 |
|
处理建议 |
设备将关闭对应端口和优先级的PFC功能以便您排除网络故障，请尽快修复网络故障，然后执行undo priority-flow-control deadlock threshold命令恢复对应端口和优点级的PFC功能 |
用户可根据实际组网情况，配置接口入方向或者出方向PFC报文的预警门限。预警门限用于PFC报文传输速率处于正常范围内，但需要提醒用户提前关注的情况。
当接口接收或发送PFC报文的速率达到预警门限时，系统会生成Trap和日志信息来提醒用户，以提前发现网络中的一些异常问题。例如：
· 对端设备网卡故障，不停地持续高速发送PFC帧，可以配置入方向预警门限进行监控。
· 本设备故障后不停发送PFC帧，可以配置出方向预警门限进行监控。
· 如果有双向监控需求的，可以在入和出方向都配置预警门限进行监控。
PFC报文的预警门限配置的具体命令介绍请参见产品命令手册。
(1) 进入系统视图。
system-view
(2) 进入以太网接口视图。
interface interface-type interface-number
(3) 配置入方向PFC报文的预警门限。
priority-flow-control early-warning dot1p dot1p-list inpps pps-value缺省情况下，未配置入方向PFC报文的预警门限。
(4) 配置出方向PFC报文的预警门限。
priority-flow-control early-warning dot1p dot1p-list outpps pps-value缺省情况下，未配置出方向PFC报文的预警门限。
|
显示内容 |
显示命令 |
|
显示PFC功能在端口上的配置情况及每端口和每队列的PFC帧的收发总量和收发速率 |
display priority-flow-control |
|
显示接收及发送端丢包的总信息及各端口丢包信息 |
display packet-drop |
# 显示所有接口的PFC信息。
<Sysname> display priority-flow-control interface
Conf -- Configured mode Ne -- Negotiated mode P -- Priority
Interface Conf Ne Dot1pList P Recv Sent Inpps Outpps
WGE1/0/1 Auto On 0,2-3,5-6 0 178 43 12 15
表5-3 display priority-flow-control interface命令显示信息描述表
|
字段 |
描述 |
|
Conf -- Configured mode |
本地配置的PFC功能的状态 |
|
Ne -- Negotiated mode |
PFC功能状态的协商结果 |
|
P -- Priority |
开启PFC功能的802.1p优先级 |
|
Interface |
接口简名 |
|
Conf |
本地配置的PFC功能的状态： · Auto表示接口与对端自动协商是否开启PFC功能 · Off表示接口下未开启PFC功能 · On表示接口下已开启PFC功能 |
|
Ne |
PFC功能状态的协商结果： · Off表示接口PFC处于未开启状态 · On表示接口PFC处于开启状态 |
|
Dot1pList |
开启PFC功能的802.1p优先级队列，共8个（0～7）优先级队列 |
|
P |
开启PFC功能的802.1p优先级队列中，有数据帧收发的优先级队列，收发帧数据为0的队列不显示 |
|
Recv |
收到的PFC PAUSE帧数量 |
|
Sent |
发送的PFC PAUSE帧数量 |
|
Inpps |
对应优先级入方向接收PFC帧的速率，单位为pps |
|
Outpps |
对应优先级出方向发送PFC帧的速率，单位为pps |
# 显示接口Twenty-FiveGigE1/0/1丢弃报文的信息。
<Sysname> display packet-drop interface twenty-fivegige 1/0/1
Twenty-FiveGigE1/0/1:
Packets dropped due to Fast Filter Processor (FFP): 261
Packets dropped due to STP non-forwarding state: 0
Packets dropped due to insufficient data buffer. Input dropped: 0 Output dropped:0
Packets of ECN marked: 0
Packets of WRED droped: 0
# 将所有支持本命令的接口的丢弃报文统计信息累计后再显示。
<Sysname> display packet-drop summary
All interfaces:
Packets dropped due to Fast Filter Processor (FFP): 261
Packets dropped due to STP non-forwarding state: 0
Packets dropped due to insufficient data buffer. Input dropped: 0 Output dropped:0
Packets of ECN marked: 0
Packets of WRED droped: 0
表5-4 display packet-drop命令显示信息描述表
|
字段 |
描述 |
|
Packets dropped due to Fast Filter Processor (FFP) |
由于接口入方向数据包被过滤所导致的丢包数 |
|
Packets dropped due to STP non-forwarding state |
由于STP协议状态为discarding导致的丢包数 |
|
Packets dropped due to insufficient data buffer. Input dropped: 0 Output dropped:0 |
由于数据缓冲区不够导致丢包，入方向丢包数：0 出方向丢包数：0 |
|
Packets of ECN marked |
由于触发WRED（Weighted Random Early Detection,加权随机早期检测 ）队列门限导致ECN（Explicit Congestion Notification,显示拥塞通知 ）域被标记为11的报文数，有关WRED、ECN域的详细介绍请参见“ACL和QoS配置指导”中的“QoS” |
|
Packets of WRED droped |
由于触发WRED队列门限导致的丢包数 |
有关gRPC和数据缓冲区监控信息请参见“4.4.2 gRPC上报”。
如需使用gRPC上报PFC的帧总量及速率请指定周期采样路径buffermonitor/pfcstatistics和buffermonitor/pfcspeeds。这两个表的详细介绍请参见“Comware V7 BufferMonitor GRPC API Reference”。
关于PFC相关命令行的更多详细信息请参考对应产品“二层技术-以太网交换配置指导”和“二层技术-以太网交换命令参考”中的“以太网接口”。
ECN是构建无损以太网的必选手段之一。ECN定义了一种基于IP层及传输层的流量控制及端到端拥塞通知机制。ECN功能利用IP报文头中的DS域来标记报文传输路径上的拥塞状态。支持该功能的终端设备可以通过报文内容判断出传输路径上发生了拥塞，从而调整报文的发送方式，避免拥塞加剧。
ECN功能对IP报文头中DS域的最后两个比特位（称为ECN域）进行了如下定义：
· 比特位6用于标识发送端设备是否支持ECN功能，称为ECT位（ECN-Capable Transport）
· 比特位7用于标识报文在传输路径上是否经历过拥塞，称为CE位（Congestion Experienced）
在实际应用中，设备将ECT位为1、CE位为0的报文，以及ECT位为0，CE位为1的报文都识别为由支持ECN功能的终端发出的报文。
图6-1 DS域位置信息
图6-2 ECN域位置信息
ECN功能工作机制：
(1) 发送端设置ECN域为10，告知路径上的设备及接收端，发送端设备支持ECN功能。
(2) 中间设备发生拥塞并达到门限，拥塞设备将发生拥塞的报文ECN域设置为11，报文正常转发。
(3) 接收端收到ECN置位为11的报文，由传输层发送CNP（Congestion Notification Packet，拥塞通知报文）通知发送端。
(4) 发送端收到CNP报文，对对应的优先级的队列进行降速处理。
(5) 经过一段可配置的时间或者发送一定数量数据，发送端恢复原来的速率。
图6-3 ECN工作机制示意图
部署了ECN功能的转发设备对接收到的数据报文进行识别和处理的具体方式如下：
· 当转发设备的报文在出方向进入队列排队，该队列的长度小于下限（也称为ECN门限）时，不对报文进行任何处理，转发设备直接将报文从出接口转发。
· 当转发设备的报文在出方向进入队列排队，该队列的长度大于下限但小于上限时：
¡ 如果设备接收到的报文中ECN域取值为00，表示报文发送端不支持ECN功能，转发设备按照丢弃概率计算是否丢弃该接收的报文。
¡ 如果设备接收到的报文中ECN域取值为01或者10，表示报文发送端支持ECN功能，将按照丢弃概率来修改部分入方向报文的ECN域为11后继续转发该报文，所有入方向接收到的报文均不丢弃。
¡ 如果设备接收到的报文中ECN域取值为11，表示该报文在之前的转发设备上已经出现拥塞，此时转发设备不处理报文，直接将报文从出接口转发。
· 当转发设备的报文在出方向进入队列排队，该队列的长度大于上限时：
¡ 如果设备接收到的报文中ECN域取值为00，表示报文发送端不支持ECN功能，转发设备丢弃接收的报文。
¡ 如果设备接收到的报文中ECN域取值为01或者10，表示报文发送端支持ECN功能，将按照丢弃概率来修改部分入方向报文的ECN域为11后继续转发该报文，所有入方向接收到的报文均不丢弃。
¡ 如果设备接收到的报文中ECN域取值为11，表示该报文在之前的转发设备上已经出现拥塞，此时转发设备不处理报文，直接将报文从出接口转发。
PFC和ECN功能同时使用时，需要注意反压帧触发门限静态值（指cell资源个数）需要大于ECN功能配置high-limit值，以使ECN功能先生效。
(1) 进入系统视图。
system-view
(2) 创建WRED表，并进入WRED表视图。
qos wred queue table table-name
缺省情况下，设备上不存在WRED表。
(3) （可选）配置计算平均队列长度的指数。
queue queue-id weighting-constant exponent
缺省情况下，计算平均队列长度的指数为9。
(4) （可选）配置WRED表的参数。
queue queue-id [ drop-level drop-level ] low-limit low-limit high-limit high-limit [ discard-probability discard-prob ]
缺省情况下，WRED表在创建之后，有缺省的一套参数，low-limit的取值为100，high-limit的取值为1000，discard-prob的取值为10。
(5) 开启队列的拥塞通知功能。
queue queue-id ecn
缺省情况下，对任何队列都未开启拥塞通知功能。
(6) 退回系统视图。
quit
(7) 进入接口视图。
interface interface-type interface-number
(8) 在接口应用WRED表。
qos wred apply [ table-name ]
缺省情况下，接口没有应用WRED全局表，即接口采用尾丢弃。
同一个表可以同时在多个接口应用。WRED表被应用到接口后，用户可以对WRED表的取值进行修改，但是不能删除该WRED表。
请查看display packet-drop命令的Packets of ECN marked和Packets of WRED droped字段显示。
如需使用gRPC上报ECN标记的报文数量和WRED丢弃的报文数量请指定周期采样路径buffermonitor/ecnandwredstatistics。这个表的详细介绍请参见“Comware V7 BufferMonitor GRPC API Reference”。
命令行的更多详细信息请参考对应产品“ACL和QoS配置指导”和“ACL和QoS命令参考”中的“QoS”。
如图7-1所示，服务器Server 1、Server 2和Server 3上均安装RoCE网卡，Server 1和Server 2均通过以太网交换机Device A和Device B（本文以Device A和Device B为S6850系列交换机为例）连接Server 3，Device B与gRPC服务器相连。
为支持RoCE技术，现要求将整个网络搭建为无损以太网，具体要求为：
· 报文转发路径的所有端口都开启PFC功能，本例以实现802.1p优先级为5的报文的无损传输为例。
· Device A的Twenty-FiveGigE1/0/3端口配置ECN功能。使设备在发生拥塞时对报文进行ECN标记，最终通知发送端调整发送速率。
本例所示的组网中，拥塞的可能发生位置为Device A的Twenty-FiveGigE1/0/3端口，因此仅在该端口配置ECN功能。实际应用中如果无法预测拥塞发生的可能位置，可以在组网中的所有端口上配置ECN功能。
· 在Device A和Device B上配置数据缓冲区的监控功能，监控队列5的缓冲区使用情况。
图7-1 RoCE功能配置组网图
(1) 在开始下面的配置之前，假设设备与采集器的IP地址都已配置完毕，并且它们之间路由可达。
(2) 配置Device A
# 在接口Twenty-FiveGigE1/0/1、Twenty-FiveGigE1/0/2、Twenty-FiveGigE1/0/3上配置接口信任报文自带的的802.1p优先级，开启接口的PFC功能，并对802.1p优先级5开启PFC功能。
<DeviceA> system-view
[DeviceA] interface range twenty-fivegige 1/0/1 to twenty-fivegige 1/0/3
[DeviceA-if-range] qos trust dot1p
[DeviceA-if-range] priority-flow-control enable
[DeviceA-if-range] priority-flow-control no-drop dot1p 5
[DeviceA-if-range] quit
# 创建WRED表queue-table5，同时进入WRED表视图配置队列5的平均队列长度指数及WRED表参数并开启ECN功能。在接口Twenty-FiveGigE1/0/3上应用WRED表queue-table5。
[DeviceA] qos wred queue table queue-table5
[DeviceA-wred-table-queue-table5] queue 5 weighting-constant 12
[DeviceA-wred-table-queue-table5] queue 5 drop-level 0 low-limit 10 high-limit 20 discard-probability 30
[DeviceA-wred-table-queue-table5] queue 5 ecn
[DeviceA-wred-table-queue-table5] quit
[DeviceA] interface twenty-fivegige 1/0/3
[DeviceA-Twenty-FiveGigE1/0/3] qos wred apply queue-table5
# 开启发送数据缓冲区超门限告警功能。
[DeviceA] buffer threshold alarm egress enable
# 开启Headroom缓冲区超门限告警功能。
[DeviceA] buffer threshold alarm headroom enable
# 开启数据缓冲区丢包告警功能。
[DeviceA] buffer packet-drop alarm enable
# 开启gRPC功能。
[DeviceA] grpc enable
# 创建传感器组test1，并添加采样路径为bufferusages和headroomusages。
[DeviceA] telemetry
[DeviceA-telemetry] sensor-group test1
[DeviceA-telemetry-sensor-group-test1] sensor path buffermonitor/bufferusages
[DeviceA-telemetry-sensor-group-test1] sensor path buffermonitor/headroomusages
[DeviceA-telemetry-sensor-group-test1] quit
# 创建传感器组test2，并添加采样路径为portqueoverrunevent和portquedropevent。
[DeviceA-telemetry] sensor-group test2
[DeviceA-telemetry-sensor-group-test2] sensor path buffermonitor/portqueoverrunevent
[DeviceA-telemetry-sensor-group-test2] sensor path buffermonitor/portquedropevent
[DeviceA-telemetry-sensor-group-test2] quit
# 创建目标组collector1，并配置IP地址为192.168.2.1、端口号为50050的采集器。
[DeviceA-telemetry] destination-group collector1
[DeviceA-telemetry-destination-group-collector1] ipv4-address 192.168.2.1 port 50050
[DeviceA-telemetry-destination-group-collector1] quit
# 创建订阅A，配置传感器组test1、test2关联目标组collector1，设置传感器组test1的数据采样和推送周期为10秒。
[DeviceA-telemetry] subscription A
[DeviceA-telemetry-subscription-A] sensor-group test1 sample-interval 10
[DeviceA-telemetry-subscription-A] sensor-group test2
[DeviceA-telemetry-subscription-A] destination-group collector1
[DeviceA-telemetry-subscription-A] quit
(3) 配置Device B
# 在接口Twenty-FiveGigE1/0/1、Twenty-FiveGigE1/0/2上配置接口信任报文自带的802.1p优先级，开启接口的PFC功能，并对802.1p优先级5开启PFC功能。
<DeviceB> system-view
[DeviceB] interface range twenty-fivegige 1/0/1 to twenty-fivegige 1/0/2
[DeviceB-if-range] qos trust dot1p
[DeviceB-if-range] priority-flow-control enable
[DeviceB-if-range] priority-flow-control no-drop dot1p 5
[DeviceB-if-range] quit
# 开启发送数据缓冲区超门限告警功能。
[DeviceB] buffer threshold alarm egress enable
# 开启Headroom缓冲区超门限告警功能。
[DeviceB] buffer threshold alarm headroom enable
# 开启数据缓冲区丢包告警功能。
[DeviceB] buffer packet-drop alarm enable
# 开启gRPC功能。
[DeviceB] grpc enable
# 创建传感器组test1，并添加采样路径为bufferusages和headroomusages。
[DeviceB] telemetry
[DeviceB-telemetry] sensor-group test1
[DeviceB-telemetry-sensor-group-test1] sensor path buffermonitor/bufferusages
[DeviceB-telemetry-sensor-group-test1] sensor path buffermonitor/headroomusages
[DeviceB-telemetry-sensor-group-test1] quit
# 创建传感器组test2，并添加采样路径为portqueoverrunevent和portquedropevent。
[DeviceB-telemetry] sensor-group test2
[DeviceB-telemetry-sensor-group-test2] sensor path buffermonitor/portqueoverrunevent
[DeviceB-telemetry-sensor-group-test2] sensor path buffermonitor/portquedropevent
[DeviceB-telemetry-sensor-group-test2] quit
# 创建目标组collector1，并配置IP地址为192.168.2.1、端口号为50050的采集器。
[DeviceB-telemetry] destination-group collector1
[DeviceB-telemetry-destination-group-collector1] ipv4-address 192.168.2.1 port 50050
[DeviceB-telemetry-destination-group-collector1] quit
# 创建订阅A，配置传感器组test1、test2关联目标组collector1，设置传感器组test1的数据采样和推送周期为10秒。
[DeviceB-telemetry] subscription A
[DeviceB-telemetry-subscription-A] sensor-group test1 sample-interval 10
[DeviceB-telemetry-subscription-A] sensor-group test2
[DeviceB-telemetry-subscription-A] destination-group collector1
[DeviceB-telemetry-subscription-A] quit
请参见附录8.2 gRPC对接软件开发。
# 在Device B上显示丢弃报文信息。
<DeviceB> display packet-drop summary
All interfaces:
Packets dropped due to Fast Filter Processor (FFP): 0
Packets dropped due to STP non-forwarding state: 0
Packets dropped due to insufficient data buffer. Input dropped: 0 Output dropp
ed: 0
Packets of ECN marked: 1622267130
Packets of WRED droped: 0
以上信息表明，网络中丢包数为0，报文零丢弃。
表8-1 dot-lp缺省映射关系
|
dot1p |
lp |
|
0 |
2 |
|
1 |
0 |
|
2 |
1 |
|
3 |
3 |
|
4 |
4 |
|
5 |
5 |
|
6 |
6 |
|
7 |
7 |
本举例开发环境为Linux，编程语言为C++。
请联系H3C技术支持获取grpc_dialout.proto文件。
下载地址：https://github.com/google/protobuf/releases
下载地址：https://github.com/google/protobuf/releases
将grpc_dialout.proto文件收集到当前目录下。
$ protoc --plugin=./grpc_cpp_plugin --grpc_out=. --cpp_out=. grpc_dialout.proto
#include <iostream>
#include <grpc++/grpc++.h>
#include <grpc/grpc.h>
#include <grpc++/server.h>
#include <grpc++/server_builder.h>
#include <grpc++/server_context.h>
#include "grpc_dialout.grpc.pb.h"
#include "my_server.h"
using namespace std;
int main()
{
string server_address("0.0.0.0:50050");
DialoutTest dialout_test;
ServerBuilder builder;
cout << "runing on " << server_address << endl;
builder.AddListeningPort(server_address, InsecureServerCredentials());
builder.RegisterService(&dialout_test);
unique_ptr<Server> server(builder.BuildAndStart());
server->Wait();
return 0;
}
#include <iostream>
#include "my_server.h"
Status DialoutTest::Dialout(ServerContext* context, ServerReader< DialoutMsg>* r
eader, DialoutResponse* response)
{
DialoutMsg msg;
while (reader->Read(&msg))
{
const DeviceInfo &device_msg = msg.devicemsg();
std::cout<< "MSG INDEX: " << this->i++ << std::endl;
std::cout << "peer info: " << context->peer() << std::endl;
std::cout<< "Producer-Name: " << device_msg.producername() << std::endl;
std::cout<< "Device-Name: " << device_msg.devicename() << std::endl;
std::cout<< "Device-Model: " << device_msg.devicemodel() << std::endl;
std::cout<<"Sensor-Path: " << msg.sensorpath()<<std::endl;
std::cout<<"Json-Data: " << msg.jsondata()<<std::endl;
std::cout<<"--------------------" << std::endl << std::endl;
}
response->set_response("test");
return Status::OK;
}
using namespace grpc;
using namespace grpc_dialout;
class DialoutTest final : public GRPCDialout::Service
{
long long i = 0;
Status Dialout(ServerContext *context, ServerReader<DialoutMsg> *reader, Dia
loutResponse *response) override;
};
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
SOURCES = $(wildcard $(subdir)*.cc)
SRCOBJS = $(patsubst %.cc, %.o, $(SOURCES))
CC = g++
%.o:%.cc
$(CC) -std=c++11 -I/usr/local/include -pthread -c $< -o $@
all: server
server: grpc_dialout.grpc.pb.o grpc_dialout.pb.o my_server.o main.o
$(CC) $^ -L/usr/local/lib `pkg-config --libs grpc++ grpc` -Wl,--no-as-n
eeded -lgrpc++_reflection -Wl,--as-needed -lprotobuf -lpthread -ldl -lssl -o $@
#chmod 777 $@
clean:
rm *.o
支持
