前面刚使用VSR1000做了打流测试（我今天学习了一下3个perf：iperf、netperf和qperf），意外发现这个VSR的“千兆”接口竟然能转发将近万兆的流量，还是十分震惊的。
但是，一般人都不会用到、也很少接触到这么大的带宽，一般也就是100M、200M或者500M。实际场景中因为带宽小，用户多的时候带宽就会拥挤，毕竟还没听说谁家接了10G的宽带了，这个时候又要配置拥塞管理/带宽保障。
这个时候一般就是采用QoS进行管理了，常用的QoS技术一般包括：流分类、流量监管、流量整形、限速、拥塞管理、拥塞避免等。同时，QoS又可以分为三种服务模型：
1、Best-Effort service，尽力而为的服务模型，也称为BF，通过FIFO（First in First out，先入先出）队列来实现，是最简单的服务模型；
2、Integrated service，综合服务模型，简称IntServ，使用RSVP（Resource Reservation Protocol，资源预留协议）协议。RSVP运行在从源端到目的端的每个设备上，可以监视每个流，以防止其消耗过多资源，所以对设备的要求很高，可扩展性很差，难以在Internet核心网络实施；
3、Differentiated service，区分服务模型，简称DiffServ，是一个多服务模型。与IntServ不同，它不需要通知网络为每个业务预留资源。区分服务实现简单，扩展性较好。
听说，DiffServ服务模型目前发展比较好，相关的RFC协议有2430、2474、2475、2983、3260、3754等等，后面应该会看到这里面的部分文章。
闲言少叙，试试H3C的VSR能支持哪些吧。
1、lr
Line Rate (LR)，一般用于配置接口限速，直接限制接口上发送报文的总速率。
配置命令：
qos lr outbound cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ]其中cir（Committed Information Rate，承诺信息速率）的单位是kbps，cbs（Committed Burst Size，承诺突发尺寸）和ebs（Excess Burst Size，超出突发尺寸）的单位是字节，cbs的配置范围是1000-1000000000，默认值为cir在0.5秒内发送的字节数，比如我们限制接口总速率为40M，命令如下：
qos lr outbound cir 40000配置成功之后，接口显示命令如下：
那字节数为40000*1000*0.5/8=2500000字节，和默认配置的字节数相同。
进行打流测试，客户端测得平均带宽为42.9M（发送端）、42M（接收端），但看过程，带宽更接近38.5M左右。
查看服务器端，平均带宽为41.8M，但看过程，带宽更接近38.3M左右，比客户端数据略低。
注意到默认发送的报文大小时128K，接口MTU为1500字节，所以应该是有一部分报文头损失的。我们按38.3/40*1500=1436字节算，得到大概传输的数据长度为1436字节。一定程度上讲，修改MTU大小应该会影响实测速率。
然后，将VSR的接口MTU修改到支持的最大的9216字节。再次测试：
多少算是有点影响吧。
2、car
Committed Access Rate (CAR)，属于流量监管。一般要和QoS、ACL搭配使用，定义流分类和流行为，因为有ACL的加持，所以流量识别就能细化到协议级别或者应用级别。
配置命令：
（绝对值配置方式）
car cir committed-information-rate [ cbs committed-burst-size ] pir peak-information-rate [ ebs excess-burst-size ] [ green action | red action | yellow action ] *（百分比配置方式）
car cir percent cir-percent [ cbs cbs-time ] pir percent pir-percent [ ebs ebs-time ] [ green action | red action | yellow action ] *那就先试一下百分比方式，确认看是不是以千兆为基准。命令如下：
#traffic classifier car1 operator andif-match acl 3402#traffic behavior car1car cir percent 10 cbs 500 pir percent 12 ebs 500 green pass red discard yellow pass#qos policy car1classifier car1 behavior car1#interface GigabitEthernet2/0description link01-141ip address 11.1.1.1 255.255.255.0qos apply policy car1 inboundqos apply policy car1 outbound#acl advanced 3402rule 0 permit ip source 11.1.1.2 0 destination 13.1.1.2 0rule 5 permit ip source 13.1.1.2 0 destination 11.1.1.2 0进行打流测试，客户端侧数据如下：
服务器端数据如下：
测得最终带宽约为120M，说明百分比基准速率取得是接口状态的千兆速率，并且一直限制在PIR（Peak Information Rate，峰值信息速率）的12%，也就是120M在跑，一定程度上说明PIR优于CIR。取消PIR配置，再测一遍。
客户端侧数据如下：
服务器端数据如下：
可以看到，测试带宽已经回落到100M。
再使用绝对值试一下，将带宽大小配置为50M，再测一遍。
客户端侧数据如下：
服务器侧数据如下：
然后我们测一下VM1和VM2的互访带宽，因为ACL里面我们匹配的是VM1和VM3的互访流量，所以VM1和VM2的互访应该是不受影响的。测试一下：
果然，未匹配到的流量不受影响。
前面提到的配置QoS策略的操作称为MQC（Modular QoS Configuration，模块化QoS配置）方式。当然，CAR也可以直接在接口下进行配置，命令如下：
qos car { inbound | outbound } any cir committed-information-rate [ cbs committed-burst-size ] pir peak-information-rate [ ebs excess-burst-size ]而且可以和QoS策略里面的CAR并存，配个例子给大家看看：
#interface GigabitEthernet2/0description link01-141ip address 11.1.1.1 255.255.255.0qos apply policy car1 inboundqos apply policy car1 outboundqos car inbound acl 3402 cir 30000 cbs 1875000 ebs 0 green pass red discard yellow passqos car outbound acl 3402 cir 30000 cbs 1875000 ebs 0 green pass red discard yellow pass但是生效确实QoS策略里面的优先，打流如下：
带宽还是50M，取消QoS策略再试一下。
发现带宽已经限制到30M了。
3、gts
Generic Traffic Shaping (GTS)，流量整形，是一种主动调整流量输出速率的措施。与流量监管不同，流量整形对流量监管中需要丢弃的报文进行缓存，但也可能会增加延迟。
配置方式和CAR类似，也支持MQC方式和非MQC方式。非MQC方式配置命令为：
qos gts any cir committed-information-rate [ cbs committed-burst-size ] pir peak-information-rate [ ebs excess-burst-size ] [ queue-length queue-length ]可以发现，GTS不再区分inbound方向和outbound方向，毕竟人家说了，是调整的输出速率。
为了操作简单，本初就直接使用非MQC方式进行以下简单测试。限速60M，配置如下：
#interface GigabitEthernet4/0description link01-141ip address 13.1.1.1 255.255.255.0qos gts acl 3402 cir 60000 cbs 3750000 ebs 0 queue-length 50打流测试，客户端侧结果如下：
带宽被限制到60M左右，再看一下服务器端结果。
看一下VSR接口的GTS统计信息。
可以看到，受令牌桶的影响，有延迟发送的报文，也有丢弃的报文，说明令牌桶确实是在工作的。
4、carl
CAR list（carl），基于CAR列表的流量监管配置。为什么不跟car放在一起看呢？因为carl与lr、car和gts不同，其他几个都是转发或者丢弃，而carl中涉及到了优先级，流量监管行为可以是改变优先级并转发、改变优先级并进入下一级监管等。
配置命令如下：
qos carl carl-index { dscp dscp-list | mac mac-address | mpls-exp mpls-exp-value | precedence precedence-value | { destination-ip-address | source-ip-address } { range start-ip-address to end-ip-address | subnet ip-address mask-length } [ per-address [ shared-bandwidth ] ] }一旦引入dscp（Differentiated Services Code Point，差分服务代码点），就有了优先级的概念，而优先级一般是用来做业务保障的。所以将carl和car分开来看。
而一定程度上将，从配置上也可以看出，carl更多的是替代ACL的使用，比如之前经常配置的每IP限速，命令如下：
qos carl 99 source-ip-address subnet 11.1.1.1 24 per-address （shared-bandwidth）我们先来一个带shared-bandwidth的配置。
#qos carl 99 source-ip-address subnet 11.1.1.1 24 per-address shared-bandwidth#interface GigabitEthernet4/0description link03-143ip address 13.1.1.1 255.255.255.0qos car outbound carl 99 cir 100000 cbs 6250000 ebs 0 green pass red discard yellow pass打个流测试一下。客户端侧结果：
服务器端结果：
这个里面有个说法，shared-bandwidth表示网段内存在流量的IP地址均分配置的共享带宽，cir为该网段内所有IP地址的共享带宽，根据当前存在流量的IP地址数量，动态平均分配各IP地址占用的带宽。而现在11.1.1.0/24这个网段只有一个主机，那就再挂一个主机上来。
再测试一下，客户端侧结果：
呃，还是100M，没有生效啊。
换成不带shared-bandwidth的配置，per-address表示对网段内逐IP地址流量进行限速，cir为各IP地址独享的限制带宽，不能被网段内其他IP流量共享。
qos carl 99 source-ip-address subnet 11.1.1.1 24 per-address再测试一下，客户端侧结果：
还是稳稳的100M，至少和描述不冲突。两个客户端同时打流，都是100M。新增的主机4结果如下：
如果不指定per-address，将对整个网段的流量进行限速，cir为该网段内所有IP地址带宽之和，各个IP地址带宽按照流量大小的比例进行分配。再次将两个主机同时打流，主机1结果如下：
主机VM4结果如下：
可以看到带宽发生抢占时，可用带宽降低。确实有效果！
总结
1、QoS的配置方式分为MQC方式和非MQC方式。MQC方式通过QoS策略定义不同类别的流量要采取的动作，并将QoS策略应用到不同的目标位置（例如接口）来实现对业务流量的控制。非MQC方式则通过直接在目标位置上配置QoS参数来实现对业务流量的控制。例如，在接口上配置限速功能来达到限制接口流量的目的。
2、有些QoS功能只能MQC方式或非MQC方式来配置，有些使用两种方式都可以进行配置。在实际应用中，两种配置方式也可以结合起来使用，但是对于相同配置存在生效先后顺序的问题，需要注意；
3、CAR的配置支持绝对值配置方式和百分比配置方式，需要注意的是，百分比配置方式一般是以应用接口的物理速率为基础的，如果实际应用中是租赁的运营商带宽，则建议使用绝对值方式进行配置；
4、配置CAR时不建议使用PIR，从测试可知，PIR一定程度上导致了CAR的限速失去意义，一直以PIR限速带宽在转发；
5、GTS和CAR相对，多了延迟转发的选项，这一功能也可能会导致数据时延增加，敏感数据谨慎使用；
6、CARL的使用和ACL功能类似，用于识别流量信息，能基于DSCP、MPLS-EXP、precedence等区分流量，但是对业务的转发类型掌握成都要求较高；
7、今天体验到了用户所说的每IP限速不生效的问题，看来像是一个功能问题。
声明：来自铁军哥，仅代表创作者观点。链接：https://eyangzhen.com/3382.html
