QOS(Quality of Service)基本原理及配置示例

发布时间:2024年01月07日

个人认为,理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息,更加便于理解协议。

由于QOS(Quality of Service)在报文上主要是更改特定字段进行流量的差异化服务,因此此处重点介绍各种服务模型及其实现原理。

自动换行
关于QOS实现上还存在大量相关资料,这里仅介绍一点关于IP QOS的实现方式及原理。

Note:第一章主要简介了QOS相关背景。有相关基础可以直接阅读第二和三章节。
个人能力有限,敬请各位指导。

目录

1.背景介绍

1.1.QOS需求

在传统的IP网络中,所有的报文都被无区别的等同对待,对报文传送的可靠性、传送延迟等性能不提供任何保证。
随着IP网络上新应用的不断出现,对IP网络的服务质量(QOS, Quality of Service)也提出了新的要求,例如VoIP等实时业务就对报文的传输延迟提出了较高要求,如果报文传送延时太长,用户将不能接受(相对而言,E-Mail和FTP业务对时间延迟并不敏感)。为了支持具有不同服务需求的语音、视频以及数据等业务,要求网络能够区分出不同的通信.进而为之提供相应的服务。传统IP网络的尽力服务(BE, Best Effort)不可能识别和区分出网络中的各种通信类别,而具备通信类别的区分能力正是为不同的通信提供不同服务的前提,所以说传统网络的尽力服务(BE, Best Effort)模式己不能满足应用的需要。

传输带宽
传输路径上的带宽遵循木桶理论,由传输链路上最小链路的带宽所限制。

端到端时延
传输时延由以下部分组成:传输时延+处理时延+队列时延+串行化延时。

因此端到端的时延由每条传输链路上的传输时延叠加而来。

QOS模型:对于不同的服务要求,常用的QOS服务模型有以下几种。

Best-Effort Services:尽力而为,最简单的服务模型。应用程序可以在任何时候,发出任意数量的报文,而且不需要事先获得批准,也不需要通知网络。

Integrated Services:集成服务模型。它可以满足多种QoS需求。这种服务模型在发送报文前,需要向网络申请特定的服务。例如,RSVP为业务事前分配相应的服务模板。但仅能为特定业务类型进行服务模板分配,并且通常需要所有节点都支持该功能。

Differentiated Services:差分服务模型。通过设置报文头部的Qos参数仪息,来告知网络节点它的QoS需求。报文传输路径上的各个路由器都可以通过对报文头的分析来获知报文的服务需求类别。

QOS的相关技术
在这里插入图片描述对于 QOS 技术,总的来说有如上所示处理流程。

流量分类与标记主要用于接口入方向,可用于后续的进一步数据处理。
监管与整形主要用于限制流量大小,提高网络资源使用效率。
拥塞管理与避免主要用于在发生拥塞之后的报文处理原则以及如何缓解网络拥塞。

1.2.相关术语

TOS:Type of Server,IP协议中的服务类型字段。表示数据包对应的服务类别,如最小延迟、最大吞吐量、最高可靠性等。
IP Precedence:IP 优先级,利用 IP 头部中1字节 TOS 字段的前3bits进行数据包分类的一种方式。定义于早期RFC中,取值越大越优。
DSCP:Differentiated Services Code Point,差分服务代码点。其基本原理利用 IPv4/IPv6 头部中1字节 TOS/Traffic Class 字段的前 6bits 来区分优先级,随后接收到报文的设备基于 DSCP 码对报文执行相应的策略。定义于 RFC2474 中。

@RFC3168-The Addition of Explicit Congestion Notification (ECN) to IP 定义了其余 2bits 为 ECN(Explicit Congestion Notification,显式拥塞通知)。在这里插入图片描述//其中 ECN 为 00 时表示 Not-ECT 未启用 ECT (Explicit Congestion Notification,显式拥塞通知);为 01/10 时表示 ECT(1)/ECT(0) 发送端和接收端开启了ECN功能;为 11 时表示 CE 路由器发出拥塞指示。
@:IPv6 除使用 Traffic Class 字段进行 QOS 外,还可利用 20bits 的 Flow Label 进行相应控制。RFC6437-IPv6 Flow Label Specification 定义了新的流标签规范。流通常指由发送端发送给指定单播地址、任播地址或组播地址的一串数据包,由发送端基于三元组(源地址、目的地址和流标签)将其标记为一个流。

PHB:Per-Hop Behavior,每一跳行为。PHB 是 DS 节点作用于数据流的行为。网络管理员可以为节点配置 DSCP 到 PHB 的映射关系。如果 DS 节点收到一个报文,依照其 DSCP 来转发。如果未匹配,则采用缺省 PHB(Best-Effort, DSCP = 000000)行为转发处理。每个 DS 节点必须支持该缺省 PHB。

点击此处回到目录

2.流量分类与标记

2.1.流量分类

流量分类
简单流分类:简单流分类是指采用简单的规则,如IP报文头中的 DSCP/IP Precedence 值,MPLS Label 中 EXP 值,Vlan 报文头中的 802.1P 值,等,对报文进行粗略的分类,以识别出具有不同优先级或服务等级特征的流量。
复杂流分类:复杂流分类是指采用复杂的规则,如结合链路层、网络层、传输层信息、等的组合,对报文进行精细的分类。通常在 Differentiated Services 域的边界路由器上对流量进行复杂流分类。

复杂流分类通常需要消耗设备一定 CPU 资源,并且由于无法在报文上体现通常需要在每一台设备上进行配置。这也就是常说的 PHB 行为。

分类的手段
常用的流量分类的手段有 ACL (Access Control Lists,访问控制列表)、SAC (Smart Application Control,智能应用控制)、NBAR (Network Based Application Recognition,基于网络的应用识别)。

ACL 主要通过IP报文中的 MAC、IP、协议号、端口号等字段对流量进行相应的抓取和识别。

SAC 则主要通过数据包应用层中的某些特征码来具体识别相应的流量。并且特征码往往受设备型号、应用版本等因素而需要实时更新,后续基于应用程序去制定智能选路、QOS、应用体验优化、安全策略等。

NBAR 是 CISCO 的 AVC(Application Visibility and Control,应用程序可见性和控制)解决方案套件中具有 QOS 支持的网络流量分类引擎。NBAR 可以通过查看数据包的 TCP/UDP 端口号对应用程序流量进行分类。或查看 TCP/UDP 有效负载本身,并根据有效负载中的内容(例如 transaction identifier,消息类型或其他类似数据)对数据包进行分类。NBAR 还可以按 URL、主机或 Multipurpose Internet Mail Extension(MIME,多用途因特网邮件扩展) 类型对 HTTP 通信进行分类。

四种公认的 PHB

前文我们提到 IPv4/IPv6 的 OQS 差分服务,主要是利用报文中1字节的 TOS/Traffic Class 字段进行差异化服务。RFC3168-The Addition of ECN to IP 又将其分为了 6bits 的 DSCP (Differentiated Services Code Point,差分服务代码点) 和 2bits 为 ECN(Explicit Congestion Notification,显式拥塞通知)。
自动换行
即使有 6bits 共 64 个之多,我们后续介绍的 DSCP 值可能也只有 20 多个。这是因为 RFC 将 DSCP 分为了 Pool1、Pool2 和 Pool3,并做了相应保留。

  • Pool1:目前主流标准化使用,取值 XXXXX0。共 32 个。
  • Pool2:为实验或本地使用,取值 XXXX11。共 16 个。
  • Pool3:先前为实验或本地使用,目前计划作为标准化使用,取值 XXXX01。共 16 个。目前仅标准化 1 个为 Lower Effort = 000001。

自动换行
关于 DSCP 的详细分类可查看 IANA 发布的 Differentiated Services Field Codepoints (DSCP)因此,这里只介绍 Pool1 所常用的 DSCP 值。其他 PHB ,例如VOICE-ADMIT 和 Lower Effort 等,感兴趣者可查阅相关资料。

  1. Default PHB(BE):缺省的 PHB 行为,取值000000。对数据流采用 FIFO(First In First Out,先进先出)的方式进行转发。
  2. Class-Selector PHB(CS):6bits 的后 3bits 置 0,取值 XXX000。0, 8, 16, 24, 32, 40, 48, 56 共 8 种分别对应 IP-Precedence 的 0-7。定义于RFC2474- Definition of the DS Field in the IPv4 and IPv6 Headers,主要用于实现与 IP-Precedence 格式兼容。

Class-Selector PHB前3个bit用于区分协议和流量
000=0 CS0表示普通routing precedence
001=1 CS1表示优先date priority
010=2 CS2表示快速date immediate precedence
011=3 CS3表示闪速voice flash precedence
100=4 CS4表示急速voice flash override precedence
101=5 CS5表示语音报文,critical precedence
110=6 CS6表示网间控制Internetwork Control (通常用于协议报文,例如OSPF等)
111=7 CS7表示网络控制network Control
该优先级只在 QOS 队列下才有意义,用户级应用仅能使用 0~5。

  1. Assured Forwarding PHB(AF):确保转发 PHB,取值 001XX0-100XX0。定义于RFC2597-Assured Forwarding PHB Group,主要用于带宽保证。

AF类 PHB:2 bits 的丢弃位(高位的第4和第4bit位),越大丢弃程度越高,AF共4种,每种可分为3个丢弃优先级。

AF1类二进制十进制
AF1100101010
AF1200110012
AF1300111014
AF2类二进制十进制
AF2101001018
AF2201010020
AF2301011022
AF3类二进制十进制
AF3101101026
AF3201110028
AF3301111030
AF4类二进制十进制
AF4110001034
AF4210010036
AF4310011038

不同类具有相同的丢弃优先级概念
例如,AF11、AF21、AF31 丢弃优先级相同;但是 AF11、AF22、AF43 中 AF43 的xxbit为 11 因此丢弃优先级最高,最先 AF21 其次,AF11 最后。

  1. Expedited Forwarding PHB(EF):快速转发 PHB,取值 101110=46。定义于RFC3246-Assured Forwarding PHB Group

当我们总结前文,就可以得到不同 DSCP 之间的优先级关系。
在这里插入图片描述//需要注意的是,以上说明仅是一个默认的相应结果。在完成报文的标记后,还需要根据后续的策略对报文进行相应的处理。

相应的参考命令
在这里插入图片描述//traffic classifier用来创建一个流分类并进入流分类视图
在这里插入图片描述//if-match 8021p 用来在流分类中创建基于相应规则进行分类的匹配规则。

2.1.1.信任域和ping tos

信任域
通常情况下,设备对于接收到的报文默认其不具有 QOS 信任度。这种方式通常指的是,不认为接收到的报文具有合理的 QOS 分类。通过这种方式一方面可以防止业务转发安全,另一方面可以基本设备自身需要提供相应的增值服务。

在这里插入图片描述//trust 用于设置基于端口的接收报文的信任报文类型。默认不信任。

ping tos
对于设备还提供一种可以设置 ICMP 报文 DSCP 值的 ping 行为:
在这里插入图片描述//ping -tos 可以设置 ICMP 的 TOS 字段。

在这里插入图片描述//指定设置 TOS 字段为 128=1000 0000 也即对应 CS4=32=100 000。
在这里插入图片描述//报文中显示携带 CS4 标记。

2.2.流量标记

在完成流量分类后就需要对流量报文进行相应的标记。常用的标记手段有优先级映射,PBR,traffic-remark(仅交换机支持),MQC(Modular QoS Command-Line Interface,模块化QoS命令行)和 QPPB (QOS Policy Propagation Through the Border Gateway Protocol)等。

在首先介绍优先级映射的概念之前,应当首先提出队列的概念。通常设备每个接口都存在一个 0-7 共 8 个转发队列,不同队列之间具有不同的优先级。关于队列的概念,将于第4章进行详细介绍。
优先级映射的目的在于将收到的报文分别映射入不同的队列中,随后依照相应的策略进行转发或者丢弃。

优先级映射
当设备接收到报文,其报文中的外部优先级字段(包括802.1p、DSCP和MPLS EXP)都被映射为内部优先级,后续可通过报文的内部优先级对报文进行进一步处理。
当设备发出报文时,将内部优先级映射为某种外部优先级字段,以便其他设备根据报文的优先级提供相应的QoS服务。
需要说明的是:报文进入设备时进行的外部优先级映射内部优先级时不涉及报文字段的修改,而内部优先级映射外部优先级时往往涉及 TOS/Traffic Class 等字段的修改。

802.1p的3bits优先级在这里插入图片描述MPLS EXP优先级在这里插入图片描述DSCP优先级在这里插入图片描述这里采用的是DSCP格式,IP Precedence则仅使用TOS字段的前3bits。

缺省的映射关系
对于入向的802.1p帧有

Input 802.1pOutput DSCPOutput Local Precedence
000
181
2162
3243
4324
5405
6486
7567

对于入向的MPLS Label EXP有

Input MPLS EXPOutput Local Precedence
00
11
22
33
44
55
66
77

对于入向的DSCP有

Input DSCPOutput 802.1pOutput Local Precedence
0-700
8-1511
16-2322
24-3133
32-3944
40-4755
48-5666
56-6377

在这里插入图片描述//traffic behavior命令用来定义一个流行为并进入流行为视图。
在这里插入图片描述//remark用来在流行为中创建重标记的动作。
在这里插入图片描述//traffic policy命令用来创建一个流策略并进入流策略视图。
在这里插入图片描述//classifier behavior用来在流策略中为指定的流分类配置所需流行为。

2.2.1.优先级映射/简单流分类实例

在这里插入图片描述实验目的:在AR2上将来自AR1的普通业务流(DSCP=0)在出方向映射为较高优先级(DSCP=10)。

关键配置

#
 sysname AR2
#
qos map-table dscp-dscp
  input 0 output 10
#
interface GigabitEthernet0/0/0
 ip address 10.1.2.2 255.255.255.0 
 trust dscp override
#
interface GigabitEthernet0/0/1
 ip address 10.2.3.2 255.255.255.0 
#

在这里插入图片描述//display qos map-table dscp-dscp可看到默认的DSCP优先级已被更改为10。

最终效果
入向有:
在这里插入图片描述//普通业务流默认为BE/DSCP=0。

出向有:
在这里插入图片描述//此时已成功更改为DSCP=10。

1@:以上操作仅根据报文的入方向优先级映射至出方向优先级,是一种简单的简单流分类及标记。复杂流分类和标记的实现需要使用 MQC 方式进行配置,也即先后使用 traffic classifier、traffic behavior 和 traffic policy 对特定业务流进行配置。
2@trust 端口通常配置于 QOS 域边界设备上。

2.2.2.复杂流分类及标记实例

此处仅给出简单配置,并需要注意指定的方向!!!

#
 sysname AR2
#
acl name test 3999  
 rule 10 permit icmp destination 3.3.3.3 0 icmp-type echo dscp default 
#
traffic classifier test operator or
 if-match acl test
#
traffic behavior test
 remark dscp af11
#
traffic policy test
 classifier test behavior test
#
interface GigabitEthernet0/0/1
 traffic-policy test outbound
#

点击此处回到目录

3.流量监管和流量整形

3.1.令牌桶Token Buckets

令牌桶技术主要用于对流量的规格进行评估,通过判断流量是否超出了规格,然后根据评估结果实施调控。

目前令牌桶主要有两种实现方式:RFC2697-A Single Rate Three Color Marker定义的单速双桶算法,以及RFC2698-A Two Rate Three Color Marker定义的双速双桶算法

需要说明的是,以下概念基于 RFC 所标准化内容并参考其他内容给出。厂商实际工作时可能有所不同。

基本原理
系统以令牌作为流量的衡量单位。系统按设定的速度向桶中放置令牌,当桶中令牌满时,多出的令牌溢出,桶中令牌不再增加。数据转发时,每转发特定流量就取走桶中的特定令牌数。如果桶中缺少令牌,则不得转发流量。

数据实际的动作可为丢弃或者重标记。

相关术语
CIR:Committed Information Rate,承诺信息速率。表示向C桶中投放令牌的速率,即C桶允许传输或转发报文的平均速率。
CBS:Committed Burst Size,承诺突发尺寸。表示C桶的容量,即C桶瞬间能够通过的承诺突发流量。
Tc:Token count with C,C桶令牌数。表示某一时刻下C桶中的令牌数。

EBS:Excess Burst Size,超额突发尺寸。表示E桶的容量,即E桶瞬间能够通过的超出突发流量。EBS 必须大于 CBS
Te:Token count with E,E桶令牌数。表示某一时刻下E桶中的令牌数。

PIR:Peak Information Rate,峰值信息速率。表示向C桶中投放令牌的速率,即C桶允许传输或转发报文的平均速率。PIR 必须大于 CIR。
PBS:Peak Burst Size,峰值突发尺寸。表示P桶的容量,即P桶瞬间能够通过的峰值突发流量。PBS 必须大于 CBS
Tp:Token count with p,P桶令牌数。表示某一时刻下P桶中的令牌数。

自动换行
单速单桶双色:系统仅定义一个令牌桶 C桶,一个令牌速率 CIR。

  • 初始时 C桶 为满桶容量为 CBS,C桶 持续以 CIR 的速率填充。
  • 当一定带宽的流量通过设备时,以特定速率取走 C桶 中的令牌。此部分报文被标记为绿色。
  • 如果设备某一时刻收到大带宽的流量时,C桶 中的令牌不够。此时未取到令牌的报文被标记为红色。

上述的数学表达为:

  • Tc(0) = CBS, Tc(t+△t) = Tc(t) + △t*CIR。
  • 当某刻 t 有报文 B 到达:如果 Tc(t) >= B,报文被标记为绿色。Tc 容量减少 B 或减少至0。
  • 当某刻 t 有报文 B 到达:如果 Tc(t) < B,报文被标记为红色。

自动换行
单速双桶三色:系统定义令牌桶 C桶 和令牌桶 E桶,一个令牌速率 CIR。

  • 初始时令牌桶为满桶,C桶 和 E桶 分别具有容量 CBS 和 EBS,并且持续以 CIR 的速率填充。
  • 当一定带宽的流量通过设备时,以特定速率取走 C桶 中的令牌。此部分报文被标记为绿色。
  • 当流量增大 C桶 中令牌不够时,则超出速率部分从 E桶 中取走令牌。此部分报文被标记为黄色。
  • 流量继续增大 C桶 和 E桶 令牌都不满足条件时,将超出部分标记为红色。

上述的数学表达为:

  • Tc(0) = CBS, Tc(t+△t) = Tc(t) + △t*CIR; Te(0) = EBS,如果 Tc = CBS,Te(t+△t) = Te(t) + △t*CIR。
  • 当某刻 t 有报文 B 到达:如果 Tc(t) >= B,报文被标记为绿色。Tc 容量减少 B 或减少至0。
  • 当某刻 t 有报文 B 到达:如果 Tc(t) < B <= Te(t),报文被标记为黄色。Te 容量减少 B 或减少至0。
  • 当某刻 t 有报文 B 到达:如果 Tc(t) < B 且 Te(t) < B,报文被标记为红色。Tc 或 Te 都不减少。

需要注意的是令牌桶技术是基于报文的,并且当转发报文时,优先选择从C桶减少令牌。这种设计可以防止瞬时大报文导致 Tc(t) >Te(t) 下小尺寸报文的错误标记。

@这里需要进行解释的是
“C桶 和 E桶 分别具有容量 CBS 和 EBS,并且持续以 CIR 的速率填充。”
所描述的含义应当是,C桶 和 E桶 共享 CIR 的填充速率而非分别具有 CIR 的填充速率,并且 E桶 容量的增加应当来源于 C桶 容量的溢出。否则,实际上造成的效果为具有 2倍 所约定的限制速率。
@:RFC2697也将这种方式称为 srTCM (Single Rate Three Color Marker,单速三色标记法)。
@:RFC2697定义CIR 以每秒 IP 数据包的字节数为单位,即它包括 IP 报头但不包括链路报头。CBS 和 EBS 以字节为单位。
@:RFC2697说明以上算法工作于色盲(Color-Blind)模式,另一种模式为色敏(Color-Aware)模式。色敏模式下,可对已着色的报文进行处理。其规则为:

  • 如果报文已被标记为绿色且 Tc(t) >= B,报文被标记为绿色。Tc 容量减少 B 或减少至0。
  • 如果报文已被标记为黄色且Te(t) >= B,报文被标记为黄色。Te 容量减少 B 或减少至0。否则报文被标记为红色。
  • 如果报文已被标记为红色,则以红色方式进行处理。

自动换行
此外,复杂流分类下的色敏工作模式还需取决于实际情况。例如,单速单色桶无黄色标记的概念。在这里插入图片描述//令牌桶默认工作于色盲模式。流行为可进行工作模式的修改,但仅限于特定设备。
@:对于不同着色的报文,可进行不同修改。绿色报文默认转发,黄色报文默认转发,红色报文默认丢弃。
@:对于不同着色的报文,还可针对进行保证级别设置。例如,绿色报文低丢弃转发,黄色尽力转发,红色丢弃。

自动换行
双速双桶三色:系统定义两个令牌桶 C桶 和 P桶 ,两个令牌速率 CIR 和 PIR。且 PIR > CIR。

  • 初始时令牌桶为满桶,C桶 具有容量 CBS 并且持续以 CIR 的速率填充;P桶 具有容量 PBS 并且持续以 PIR 的速率填充。
  • 当一定带宽的流量通过设备时,以特定速率同时取走 P桶 和 C桶 中的令牌。此部分报文被标记为绿色。
  • 当流量增大 C桶 中令牌不够时,以特定速率从 P桶 中取走令牌。此部分报文被标记为黄色。
  • 流量继续增大 C桶 和 P桶 令牌都无法满足时,将报文标记为红色。

上述的数学表达为:

  • Tc(0) = CBS, Tc(t+△t) = Tc(t) + △t*CIR; Tp(0) = PBS, Tp(t+△t) = Tp(t) + △t*PIR。
  • 当某刻 t 有报文 B 到达:如果 Tp(t) >= B 且 Tc(t) >= B,报文被标记为绿色。Tp 和Tc 容量同时减少 B 或减少至0。
  • 当某刻 t 有报文 B 到达:如果 Tc(t) < B <= Tp(t),报文被标记为黄色。Tp 容量减少 B 或减少至0。
  • 当某刻 t 有报文 B 到达:如果 Tp(t) <= B,报文被标记为红色。

@:RFC2698也将这种方式称为 trTCM (Two Rate Three Color Marker,双速三色标记法)。
@双速双桶三色可以向单速双桶三色部分兼容,也即将 PIR 设置为 CIR 即可。可向单速单桶完全兼容,也即将 PIR 设置为 CIR ,PBS 设置为 CBS 即可。单速双桶三色向单速单桶兼容时,将 EBS 设置为 0 即可。
@:HW默认情况下,单速双桶的CBS取值为CIR的188倍,双速双桶默认为125倍。
@:双速双桶的 Tp “永远”不小于 Tc,单速双桶的 Te 则有可能小于 Tc。
@:三种令牌桶模式的功能及选用场景在这里插入图片描述实际的使用可根据具体情况进行选择。

3.2.流量监管Policing

流量监管(Traffic Policing)就是监督网络的流量速率,对超出部分的流量进行“惩罚”,也即直接丢弃或降级优先级。通过这种方式使流量被限制在一个合理的范围之内,从而保护网络资源和用户的利益。

CAR:Committed Access Rate,承诺访问速率。
CAR 可以利用令牌桶来衡量每个数据报文是超过还是遵守所规定的报文速率。

基于接口的流量监管
在接口下对流量进行相应限制。
在这里插入图片描述//qos car 可用于在接口下做限速,并且可以基于 ACL 等相应规则来实现。

基于类的流量监管
也即通过 MQC 的方式进行流量监管配置。

#
traffic classifier <Policing> operator or 
 if-match vlan-id 10
#
traffic behavior <Policing>
 car cir 256 cbs 48128 pbs 80128 green pass yellow pass red discard
 statistic enable
#
traffic policy <Policing>
 classifier <Policing> behavior <Policing> precedence 5 
#
interface Ethernet2/0/0
 traffic-policy <Policing> inbound
#

3.3.流量整形Shaping

流量整形(Traffic Shaping)将上游不规整的流量进行削峰填谷,使流量输出比较平稳,从而解决下游设备的拥塞问题。

流量整形与流量监管的主要区别在于:
@流量整形对原本要被丢弃的报文进行缓存,当令牌桶有足够的令牌时,再均匀的向外发送这些被缓存的报文。流量整形与流量监管的另一区别是,整形可能会由于缓存的行为而导致增加延迟,而监管几乎不引入额外的延迟。
@:因此对于时延敏感业务,推荐使用监管;对于 TCP业务,推荐使用整形。
@此外,流量整形通常作于接口的出方向,而流量监管可用于双方向。

基于接口的流量整形
在接口下防止流量波动。
在这里插入图片描述//qos gts 配置的接口整形,是对接口下所有队列的总流量进行整形;queue gts命令配置的队列整形,是对接口下某条队列的流量进行整形。如果同一接口下既配置接口队列整形,也配置接口整形,则接口整形的cir-value必须大于等于接口上所有队列整形的cir-value之和;否则,流量整形会出现异常现象,可能会造成某些高优先级队列得不到及时调度

基于队列的流量整形
在队列下进行整形。
在这里插入图片描述//queue gts配置队列整形。接口收到的报文根据优先级映射,进入不同的队列,针对不同的优先级队列设置不同的流量整形参数,可以实现对不同业务的差分服务。
在这里插入图片描述//随后在接口下绑定相应的队列模板。

基于类的流量整形
也即通过 MQC 的方式进行流量整形配置。

#
traffic classifier <Shaping> operator or 
 if-match vlan-id 10
#
traffic behavior <Shaping>
 gts cir 256 cbs 48128 pbs 80128 green pass yellow pass red discard
 statistic enable
#
traffic policy <Shaping>
 classifier <Shaping> behavior <Shaping> precedence 5 
#
interface Ethernet2/0/0
 traffic-policy <Shaping> outbound
#

3.4.接口限速Line Rate

接口限速(Line Rate)对一个接口上发送或者接收全部报文的总速率进行限制。当无需区分数据时,可用于简化配置。
接口限速也是采用令牌桶进行流量控制,并且支持出入两个方向。

入方向的接口限速
使用入方向的接口限速时,首先需要创建car模板随后在接口下调用到入方向。
在这里插入图片描述//qos car在全局下定义car模板,随后在接口下进行调用。

出方向的接口限速
在这里插入图片描述//qos lr 用来限制接口向外发送数据的速率,即配置接口整形速率。

点击此处回到目录

4.拥塞管理和拥塞避免及队列

4.1.拥塞避免

拥塞避免(Congestion Avoidance)是指网络中在拥塞发生或有加剧的趋势时避免拥塞的进一步发生或加剧。主要通过主动丢弃报文,调整网络的流量来解除网络过载的方式。

常用丢弃机制
Tail Drop:尾丢弃。对于 新入队列的数据包(缓存在队列尾部) 进行丢弃。

这种丢弃策略有如下缺点:
TCP全局同步现象:也即多个TCP连接反复同时进入拥塞避免又同时启动而导致流量降低。
TCP饿死现象:当网络中同时存在TCP和UDP流量时。由于TCP滑动窗格的存在,当TCP会话被拥塞丢弃后,TCP会话会协商一个更小的载荷。如果网络中持续存在拥塞现象,那么最终导致将网络中的UDP流量占比将会越来越高,TCP流量占比越来越小的会话饿死现象。

RED:Random Early Detection,随机先期检测。为不同业务的报文指定不同的丢弃策略,基于丢弃参数随机丢弃报文。
增强的WRED(Weighted Random Early Detection)技术可以基于优先级设置报文丢包的上下阈值及丢包率。基于 WRED 的队列在报文到达下限时,开始丢包,随着门限的增高,丢包率不断增加,最高丢包率不超过设置的丢包率,直至到达高门限,报文全部丢弃。(不丢弃----随机丢弃----尾丢弃)
在这里插入图片描述//对于不同优先级报文的丢弃。

配置基于队列的WRED

drop-profile <test>
 wred dscp
  dscp af31 low-limit 40 high-limit 60 discard-percentage 40 
  dscp af32 low-limit 50 high-limit 70 discard-percentage 30  
#
qos queue-profile <queue-profile1>
  queue 3 drop-profile <test>
  schedule wfq 3 to 4 pq 5
#
interface GigabitEthernet3/0/0          
 qos queue-profile <queue-profile1>
#
//需要事先对入向报文进行分类和标记,或者信任相应的端口。
//需要确认DSCP优先级与本地优先级(队列)之间的关系。
//此处设置 AF32 报文的原则为:
低丢弃门限为 40%;
达到门限以不断增加的丢包率进行丢包,最大丢包率 40%;
如果超过高丢弃门限 60%,则全部丢弃。

基于 MQC 的 WRED 需要在 traffic behavior 中绑定丢弃模板:
在这里插入图片描述//drop-profile 用于在 traffic behavior 中绑定丢弃模板.

配置基于WRED模板的WRED

port-wred <test>
 color green low-limit 70 high-limit 100 discard-percentage 100
 color yellow low-limit 60 high-limit 90 discard-percentage 100
 color red low-limit 50 high-limit 80 discard-percentage 100
#
interface GigabitEthernet0/2/0
 port-queue af2 wfq weight 10 shaping 50 port-wred pw outbound
 port-queue af3 wfq weight 10 shaping 50 port-wred pw outbound
 port-queue ef pq port-wred <test> outbound
 #
//需要事先对入向报文进行分类和标记,或者信任相应的端口。
//需要确认DSCP优先级与本地优先级(队列)之间的关系。

4.2.拥塞管理/队列

拥塞管理是指网络中已经发生拥塞的情况下,通过调整报文的调度次序来满足对特定业务的机制。例如对低时延业务进行QOS,保证其有限转发。

因此在拥塞管理之前需要先对业务流进行分类,分类完成后由设备根据相应的“优先级”和策略进行转发。这一机制主要是通过队列来实现的。

队列概念
IOS在处理数据包时,将数据包储存在内存中。路由器完成了发送数据包之前所需的工作,此时如果出接口繁忙,路由器会将数据包存留在一块系统的内存缓冲区中,同时等待接口状态变为可用。为了管理这些被保留在内存中等待发送的数据包,IOS子有了队列机制。队列机制用于负责管理等待发送的数据。

队列是系统的指针,指向每个等待发送的数据包的内存中。

队列Queue特性
1@:每个数据包的大小不会影响队列的长度,也不会影响队列中可以排入的数据包数量。也即队列的大小通常反映的是最大留存于内存缓冲区中数据包的个数。有时也可指定队列大小。

在这里插入图片描述//queue length用来在队列模板中配置各队列的长度。

2@:队列不会排列数据包本身,而是排列指向数据包的指针。队列实际是指向数据包的指针。
3@:队列基于端口进行相应资源分配,端口之间不会相互影响。
4@:队列分为 Hardware Queues 硬件队列Software Queues 软件队列。数据包在发送时,通常进入软件队列。数据经软件队列排序后,进入硬件队列。仅软件队列可人为选择,硬件队列永远采取 FIFO(First In First Out,先进先出)。所执行的 QOS 策略实际上是对软件队列的控制,可选择的软件队列取决于所使用的平台及配置。

如果单位时间内收到的数据包数量较少,也有可能直接进入硬件队列进行转发。(也即,软件队列为空硬件队列未满。通常出现在大带宽低流量的情况下。)

5@:每个软件队列又可分成多个子队列。对于相应的流分类,可将数据分入不同的子队列。每个子队列根据自身相应的规则,在出接口上依次进行数据包转发。相应的分配机制称为调度机制。

6@:对于超过队列大小的数据包,系统依照队列相应的丢弃机制进行数据包的丢弃。

常用丢弃机制
Tail Drop:尾丢弃。对于最后到达队列的数据进行丢弃。这种丢弃策略会引发TCP全局同步现象,也即多个TCP连接反复同时进入拥塞避免又同时启动而导致流量降低。
RED:Random Early Detection,随机先期检测。为不同业务的报文指定不同的丢弃策略,基于丢弃参数随机丢弃报文。
增强的WRED(Weighted Random Early Detection)技术可以基于优先级设置报文丢包的上下阈值及丢包率。基于 WRED 的队列在报文到达下限时,开始丢包,随着门限的增高,丢包率不断增加,最高丢包率不超过设置的丢包率,直至到达高门限,报文全部丢弃。

4.2.1.队列调度算法

FIFO队列-First In First Out Queuing:先进先出队列
实现原理:设备仅有1个队列,优先进入队列的报文优先进行转发。

PQ队列-Priority Queuing:优先级队列
实现原理:假设共有4个子队列,PQ队列可为每个子队列定义相应的优先级: Q1=High PQ, Q2=Medium PQ, Q3=Normal PQ 和 Q4=Low PQ。

在进行数据转发时,

  • 优先转发具有较高优先级的队列流量。待高优先级队列数据传输完成后,才开始转发下一级优先级队列中数据。
  • 如果在转发低级别优先级队列数据时又有数据进入相对高级别队列中,则中断当前传输优先转发高级别队列中数据。
  • 每一个子队列都有一个最大队列深度(queue-size),如果达到了最大队列深度,则进行尾丢弃。

优点:可以较好保证高优先级流量的低时延。
缺点:如果高优先级队列中始终存在流量,则低优先级队列中的流量可能始终得不到转发出现”饿死“现象。

PQ 队列的每个子队列使用先进先出和尾丢弃机制。

在这里插入图片描述//报文转发效果。
在这里插入图片描述//schedule用来在队列模板中配置各队列之间的调度关系。此处的队列可能不仅只有4个子队列,具体的实现仍取决于具体设备。
在这里插入图片描述//相似的qos queue-profile用于在接口下调用相应的队列模板。

CQ队列-Custom Queuing:定制队列
实现原理:假设接口存在16个队列,CQ 队列允许用户为不同队列指定相应的带宽比例。在接口转发时,CQ 按定义的带宽比例分别从1到16号队列中依次取特定带宽比例/字节长度的报文在接口上发送出去。这种依次转发的队列方式,也称轮询队列。

优点:每个队列都能得到带宽,不会“饿死”。让不同业务的报文获得合理的带宽,从而既保证关键业务能获得较多的带宽,又不至于使非关键业务得不到带宽。
缺点:采用轮询调度各个队列,CQ 无法保证任何数据流的延迟。可能导致延时和抖动。

RR/WRR/DRR队列-Weighted/Deficit Round Robin:加权轮询调度/差分轮询调度
实现原理:WRR 在队列之间依照权重进行轮询调度。假如端口有8个输出队列,WRR 则可为每个队列配置一个加权值(依次为w7、w6、w5、w4、w3、w2、w1、w0),加权值表示获取资源的比重(依次为Wn/(W0+W1+…+W7),也即占总和的相应比例)。后续转发时,对于每个队列进行轮询转发。每次轮询后,每个队列的权重值降低。直到某次轮询时,队列权重值为0的队列不在转发数据不在轮询。如果所有队列的权重都降低为0,则恢复每个队列的权重值为定义的初始值重复上述转发过程。

WRR 队列基本遵循 RR 队列的原理,同时为每个子队列定义一个初始值为 0 的 赤字Deficit 值。每次调度前,系统按权重为各队列分配带宽并计算当前 Deficit 值。
如果队列的 Deficit > 0,则参与此轮调度发送报文,并根据所发送报文的长度计算调度后 Deficit 值,作为下一轮调度的依据;如果队列的 Deficit < 0,则不参与此轮调度,当前 Deficit 值作为下一轮调度的依据。

DRR与WRR的区别是:WRR 调度是按照报文个数进行调度,而DRR是按照报文长度进行调度。
如果报文长度超过了队列的调度能力,DRR 调度允许此时允许该报文进行转发以保证长报文也能够得到调度。但将其队列置为负权重,因此下次轮循调度时该队列将少调度或不会被调度。直到权重为正,该队列才会参与 DRR 调度。

优点:WRR 可以保证最低优先级队列至少获得一定比例带宽,避免了采用 PQ 调度时低优先级队列中的报文可能长时间得不到服务的缺点。
DRR 调度避免了采用 PQ 调度时低优先级队列中的报文可能长时间得不到服务的缺点,也避免了各队列报文长度不等或变化较大时,WRR 调度不能按配置比例分配带宽资源的缺点。
缺点:WRR 按照报文个数进行调度,当队列的平均报文长度变化时,用户就不能通过配置 WRR 权重获取想要的带宽。WRR 与 DRR 都存在低延时需求业务(如语音)得不到及时调度的缺点。

FQ/WFQ队列-Weighted Fair Queue:加权公平队列
实现原理:在 FQ 的基础上增加了优先权方面的考虑,使高优先权的报文获得优先调度的机会多于低优先权的报文。WFQ 可以按流的“会话”信息的 HASH 结果进行流分类,并且排入队列中去。同时以将每个流均匀地放入不同队列中,从而在总体上均衡各个流的延迟。在出队的时候,WFQ 按流的优先级(precedence)来分配每个流应占有出口的带宽。
优先级的数值越小,所得的带宽越少。优先级的数值越大,所得的带宽越多。

优点:WFQ 尽可能公平地分享网络资源,使所有流的延迟和抖动达到最优,让不同队列获得公平的调度机会。
缺点:不支持手工分类,不能提供固定带宽保证。

CBWFQ队列-Class-based Weighted Fair Queueing:基于类的加权公平队列
实现原理:CBWFQ 是对 WFQ 功能的扩展,可依照用户自定义类进行调度。CBWFQ 首先根据 IP 优先级或者 DSCP 优先级、输入接口、IP报文的五元组等规则来对报文进行分类,然后让不同类别的报文进入不同的队列。对于不匹配任何类别的报文,送入系统定义的缺省类。

CBWFQ 主要提供三种队列:EF队列、AF队列和BE队列。

  • EF队列 是具有高优先级的队列。调度出队时优先调度,以保证其获得低时延。拥塞时以不高于某阈值优先发送;不拥塞时,EF队列可以占用 AF、BE 的空闲带宽。
  • AF队列 有多个子队列是保证队列。用户可以设定每类报文占用的带宽。在系统调度报文出队列的时候,按用户为各类报文设定的带宽将报文出队列发送,可以实现各个类的队列的公平调度。当接口有剩余带宽时,AF队列按照权重分享剩余带宽。
  • BE队列 是缺省队列。

EF队列采用尾丢弃机制,AF队列和BE队列可采用尾丢弃或WRED机制。

CBWFQ 还在EF队列中定义 LLQ(Low Latency Queueing,低延迟队列)。这是一个有最小保证带宽的最高优先级队列,出现拥塞时,该队列的数据量不能超过所允许的带宽,否则会被丢弃。

优点:CBWFQ 可为不同的业务定义不同的调度策略(如带宽、时延等)。
缺点:启用 CBWFQ 特性系统存在一定的资源开销。

点击此处回到目录

更新

文章来源:https://blog.csdn.net/fengxingzhe008/article/details/132257747
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。