QOS技术指南

 为什么需要Qos-----我的理解是利用有限的带宽，来做尽可能多的服务，当然不是有限的带宽做无限的服务。。

接下来就进入正题：Qos技术的简单介绍

一 Qos的分类：

1 尽力而为的服务类型（主要技术是FIFO或者叫FCFS）

2 集中式的服务类型（主要用到的技术是RSVP---资源预留协议）

3 区分服务类型（这是当下使用最多的服务类型，使用到的技术也很多---------分类-classing，标记—marking，整形—shaping，策略---policying，拥塞避免---WRED,队列技术--queing）

二 QOS的操作方式：

1.Legacy CLI 纯命令行

2.MQC model Qos CLI 模块化的命令行（CBXX）

3.Cisco AutoQos------自动QOS

4.Cisco SDM Qos wizard---使用SDM配置Qos

三 简单介绍服务类型

1尽力而为的服务类型------ Best-Effort

采用的技术是FIFO----先进先出的技术，也可以说不做Qos的Qos技术，它尽最大的努力(Best-Effort)将报文送到目的地,但对报文传送的可靠性,传送延迟等性能不提供任何保证.

2 集中式服务模型---- Intserv

它可以满足多种QoS需求。这种服务模型在发送报文前,需要向网络申请特定的服务。应用程序首先通知网络它自己的流量参数和需要的特定服务质量

请求：包括带宽、时延等。应用程序一般在收到网络的确认信息,即确认网络已经为这个应用程序的报文预留了资源后,才开始发送报文,同时应用程序发出的报文应该控制在流量参数描述的范围以内。网络在收到应用程序的资源请求后,执行资源分配检查 Admission control 即基于应用程序的资源申请和网络现有的资源情况,判断是否为应用程序分配资源,一旦网络确认为应用程序的报文分配了资源,则只要应用程序的报文控制在流量参数描述的范围内,网络将承诺满足应用程序的QoS需求。而网络将为每个流 flow 由两端的IP地址、端口号、协议号确定、维护一个状态,并基于这个状态执行报文的分类、流量监管、policing、排队及其调度来实现对应用程序的承诺。

RSVP---资源预留协议

RSVP是第一个标准QoS信令协议,它用来动态地建立端到端的QoS,它允许应用程序动态地申请网络带宽等。RSVP协议不是一个路由协议,相反,它按照路由协议规定的报文流的路径为报文申请预留资源,在路由发生变化后,它会按照新路由进行调整,并在新的路径上申请预留资源。RSVP只是在网络节点之间传递QoS请求,它本身不完成这些QoS的要求实现,而是通过其他技术来完成这些要求的实现。(RSVP只是一种用来预定的协议)

RSVP的处理是接收方发出资源请求,按照报文发送的反向路径发送资源请求,所以它可以满足非常大的多播组,多播组的成员也可以动态变化,RSVP协议是针对多播设计的单播可以看作是多播的一个特例。

由于RSVP在Internet上还没有得到广泛的推广,在主机不支持RSVP的情况下,我们可以通过配置RSVP代理,即代替不支持RSVP的主机发送RSVP报文来获得这种服务,对报文流路径上不支持RSVP的路由器,它只需要简单的转发RSVP报文所以对RSVP协议不会有太大影响,但这些节点不会对报文提供所要求的QoS 。(这是RSVP的一个缺点)

RSVP信令在网络节点之间传送资源请求,而网络节点在收到这些请求后,需要为这些请求分配资源,这就是资源预留。网络节点比较资源请求和网络现有的资源,确定是否接受请求,在资源不够的情况下,这个请求可以被拒绝,可以对每个资源请求设置不同的优先级。这样,优先级较高的资源请求可以在网络资源不够的情况下,抢占较低优先级的预留资源,来优先满足高优先级的资源请求。

资源预留判断是否接受资源请求,并承诺对接受了的资源请求提供请求的服务,但资源预留本身不实现承诺的服务,需要通过队列等其他技术来实现。

 Intserv有它的好处,但是也有严重缺点,首先就是RSVP协议数据太多,而且不断刷新,并且这种给单一数据流的路径进行带宽预留的解决思路在浩瀚的Internet上实现简直是不可能的,而且RSVP的部署,厂商之间设备的互联,业务管理方面等存在着种种问题,所以这么模型在1994年推出之后就没有获得任何规模的商业应用。

3区分服务类型—DiffServ

A----classification 分类

ACL--------抓去流量

    Class-map分类

  网络层----ip precedence优先级和DSCP（区分服务编码点）

  链路层----Cos（802.1p），MPLS的EXP位，Frame—relay的DE位

B-----Marking----标记

Ø  PBR policy-based routing 策略路由

基于源来做区分。数据层面，优于路由表。应用在incoming 接口(数据的入方向）

Ø  CB Marking CB标记(CLI)------典型的MQC 

1.class map 分类区别各种流量

2.policy-map Action 调用class-map

3.Serice Policy 调用policy-map

C-----队列技术（qeueing）

FIFO---先进先出队列，大于2.048mbps的默认是FIFO，小于等于2.048mbps的采用WFQ

Fair-queue 是WFQ的命令，NO fair-queue 就是FIFO

在默认情况下，FIFO的出栈队列座位号为40 ,如下命令修改为100

PQ： 优先级队列---分为4类

 

需要知道的是，如果P-LIST可以抓出流量，则不用用ACL

 

PQ-list 将流量放进相应的类别（队列）

 

接口调用

CQ：用户自定义队列—可以定义17个队列（有队列0）

先抓语音流量

写CQ

调用CQ

查看配置

WFQ：加权公平队列

接口下改为WFQ

100：CDT     512：动态Q（流数）     37：为RSVP预留的队列（开始RSVP）

 

修改HQO

在WFQ当中，是没有分类一说的，只有分流（flow)

Flow:怎么才算“一个流” 在包头当中，将六元组（Sip Dip Tos Sor Dor pro) 进行hash得到摘要，进行比对如果一致，则说明是一个流

插队以及调度技术

CDT 和 HQO CDT默认为64 HQO为1000

LLQ:低延迟队列技术--是建立在WFQ的基础上，为了保证VOIP流量优先去传，并且可以为VOIP流量预留带宽

其中ip rtp priority 是启动LLQ的命令，后面的端口号，为RTP的端口号范围，表示内部为

语音流量

1200 预留带宽

在默认情况下，可用带宽为参考的带宽的75%

Exp: 参考带宽为1544 可用为1158

所以，当预留1200带宽后，会报错：

可用带宽不足，可以使用max-reseverd-bandwdth 修改为100%

CBWFQ:

CBWFQ好处

1.可以手工分类

2.指定带宽

3.2个WFQ

分类：

指定带宽比率，以及缺省队列中的WFQ

在接口下调用

检查：

Policy-map CBWFQ

Class http

Bandwidth + 参考带宽

Bandwidth persent + 参考带宽的百分比

Bandwidth remine persent + 可用带宽的百分比（参考带宽×75%的那个值）

CBLLQ:

 

WFQ/LLQ    CBWFQ/CBLLQ

1.首先需要知道的是CB和无CB之间的关系

只要看到CB了就知道是MQC（模块化的QOS命令行）

WFQ 是全自动的，无手工分类，只有自动分流

全局性的插队技术，全局性的调度技术

插队技术：CDT/HQO

调度技术：Finish time

但是它有不足，它不能为VOIP流量指定相应的预留带宽

所以思科提出了LLQ （低延迟队列）

基于WFQ的基础上（事实上命令行也是基于WFQ的）

然后通过ip rtp priority 抓出RTP的端口号范围，给予VOIP预留相应的带宽

---------------------------------------------------------------------------------------------------------------------------------

2.CBWFQ出现了，它的出现满足了，WFQ无法手工分类，并且无法预留带宽的问题

在此基础上还提出了default class里面继续运行WFQ的新式理念

但是CBWFQ虽然很好，但是也有不足，虽然可以给语音（VOIP）流量分配相应的带宽，或者叫

预留相应的带宽，但是无法优先传输

所以出现了CBLLQ，（命令行也是基础与CBWFQ的）

CBLLQ的目的是为VOIP优先传输，所以CBLLQ = PQ + CBWFQ