QOS,服务质量。顾名思义,就是为了给现有的网络提供一个更好的性能,让各种网络应用更加顺畅的运作。当然了,如果你想让网络运作的更好,那你就得了解你自己的网络啊。看看这个网络中都运行着什么网络应用,且这些网络应用比较关心的网络因素有那些,比如网络延迟、抖动、丢包率等等因素。我们就是通过控制这些对网络应用有着关键作用的因素来调节网络的正常、高速运行的。可以这样说:QOS特性就是用来修理网络数据传输过程中的一些小瑕疵的特性。只要你把这个数据路径修理的足够光滑,在某种程度来说没有任何的阻碍了,那么数据跑起来就会相当的流畅,什么丢包啊,延迟啊,延迟抖动啊就都统统解决啦。速度和质量得到了双保障。当然了,我们得对症下药,知道问题出在了那里。并且,这样还不够,我们还要知道问题“可能”出在那里!这样的话,我们就会把这种数据传输过程中的一些不良的隐患全部消除掉了。
我们使用了QOS后,可以说是我们想让网络怎么地,网络就怎么地,完全处于你的控制中。不但实现了网络数据的流畅传输,并且对网络资源的使用也做到了精确的控制,不会浪费资源,也不会让资源出现极其紧张的局面,即使有可能出现紧张的局面,那么我们也有办法来预防这种情况的发生。废话了不少,这些都是使用QOS的好处。其实,仔细看看,也不是废话,其中也谈到了很多QOS的核心内容:<?xml:namespace prefix = o />

1.       因为我们可以对各种网络应用做到了精确的控制使用资源,那么肯定就是对他们进行区别对待了,这也就是QOS中分类的概念啊。

2.       上面说到的,修理数据传输路径上的小瑕疵,以求让数据传输的更流畅,这也就是后面我们将要降到的流量调节啊。

3.       在最后面我们还提到了,出现资源紧张的局面,我们可以采取措施来搞定,这里也就说到了后面将要详细介绍的拥塞管理和拥塞避免
OK,开始正题。
QOS的好处不说了,那么我们有必要认识下QOS的俩大门派:集成QOSIntServ QOS)和区分QOSDiffServ QOS)。

来简单的介绍下他们俩个:集成的呢,就是用硬件方式来实现的。都是固化在设备里面的一些程序,也就说他们的灵活性不怎么地,这种类型的QOS只可以用在那种面向的技术升级很慢的环境中,如果升级很快的话,那么你更换设备就得跟上,那还了得啊!亏大了~~这种QOS的实现,是建立在网络对网络应用的处理行为是可预测的基础上的。它的主要实现依赖于一个重要的协议:RSVP(Resource Reservation Protocol) 资源预留协议。当一个支持RSVP的应用在发送数据之前,他们利用这个协议向RSVP网络请求特定类型的服务,并且应用将他的流量配置文件(traffice profile)发送给网络,告诉这个网络,需要按照这样的要求,给我分配资源,满足了这样的环境后,俺才发送数据咧。当网络得到确认后,才可以进行发送数据。有了这样的应用环境了,我们还得有一些控制措施啊,这就得通过在PDP(Policy Decision Point,策略决策点)使用COPS(common open policy service,通用开放策略服务)来集中完成许可控制。可以看出:这个集成QOS的实现靠的是RSVP+traffice profile + COPS来完成的。就这么点活~~~
那再看看DiffServ QOS 。这个家伙,相对前面的就比较灵活了,可以说是为现在的网络量身打做的。这个这种类型的QOS中,数据流是要进行分类的,然后,我们可以进一步的对各种不同类的流进行的控制。这个控制的实现就是通过策略表来实现的。这样简单一说,我们就该知道了,实现他们是要有个类表,然后还得有个控制表----策略表。这年头,干啥不都讲究策略啊,呵呵、、、QOS也不例外。我们现在一般使用的都是后者。所以下面详细讲解。我们通过了解他的一些特性来理解他的工作原理和工作过程
区分服务QOS有一下特性:

1.  分类

2.  标记

3.  流量调节

4.  拥塞管理

5.  拥塞避免

我们一个一个的来分析各个特性的特性和实现。
分类:顾名思义,显然就是对网络中的的数据流进行不同的分类,区别对待。那么分类的依据是什么呢?分类的方法有哪些呢?我们研究数据包的时候,有时候关心的是2层的,还有的时候是主要关心3层的。那么对于不同的层次的数据来说,分类的依据是一样的吗?分类的依据是系统默认的呢,还是可以进行人为设置的?带着问题看下面的分析!
QOS主要进行分类的依据就是DSCPdifferent services code point :区别服务编码点)。其实,这里说的这个8位的DSCP值更准确说应该是内部DSCP值。后面就会知道了。
对于2层的数据帧来说,我们使用COS来区分不同的数据流,并且这个3位的字段只出现的ISL或者802.1Q的封装帧中。存在VLAN标记中的,只占3位。
对于3层的数据包来说,我们使用的是IP数据包头中的TOS字段来表示的。TOSIP数据报头中有一个字节的长度,但是并不是所有的位都来担任进行区分不同IP数据流的服务的。而只是高6位。其中高3位表示的是IP优先级。所以我们一般看的就是IP优先级,平时的映射关系说的也是IP优先级和内部DSCP的映射。中间的3位都是0
现在看来,我们使用的是COS或者TOS的高6位。但是上面说是使用DSCP,所以就会有这俩者和DSCP(内部)之间的映射关系。不过,我们平时说的时候也是直接说DSCP,而不说COSTOS 了。
典型的以太网数据包

2层数据报头
3层数据报头
数据

 

第二层ISL

ISL包头(26字节,3位用于COS
被封装的帧
FCS4字节)

 

第二层802.1Q

              
起始帧分隔符
DA
SA
标记(3位用于COS(用户优先级))
其他第二层报头
数据
FCS

 

第三层Ipv4数据包

版本/长度
TOS(1字节)
长度
ID
标记
TTL
协议
校验和
IP-SA
IP-DA
数据
其中TOS的高3位表示IP优先级,高6位表示的DSCP值。

 

不管如何,COSTOS都是要和内部DSCP进行映射的,无论是人工映射,还是默认的映射关系。3COS3IP优先级是一样的。只是COS作用在2层,而IP优先级是对于3层。当然了,他们映射到一个内部的DSCP得到的数值也是一样的的。

 

 

OK了,就是这样,QOS通过这些就可以将非常的多的数据流,简单的规划分类为几个大的数据流,不关你原来是什么模样的,只要你进这个类,就得按照这个类的规矩办事,该减速的减速,该抛锚的抛锚。让你咋滴就咋滴。

 

 

既然说到了归类了,那就谈下,如何建立这个类吧。

分类肯定得有很多种方法吧:
1.  按接口的信任模式;
2.  按接口的手工分类;
3.  按数据包(基于ACL);
4.  NBAR(network based application recognition)基于网络应用的识别;
接口的信任模式:

当我们没有使用QOS的时候,对数据包的处理是处于尽力而为best-effort等级的,也就说从端口里进来的数据都是一个样的,根本就没类的概念。这个时候呢,如果数据包格式中有DSCP了,不管原来的是多少,只要经过端口进入到交换机的时候,都将DSCP设备为0。也就说呢,不信任以前的那些DSCP值,即使你本来的数据中包含着一个DSCP,那也白搭。现在,我们要讲的这种分类方式,就是要相信这种数据中的DSCP值,按照这些数据中本来就有的DSCP来进行分类,因为不同的接口接收的数据是不同的,有的是2层的,有的是3层的。所以呢,当我们在接口上设置这种信任数据中的DSCP的命令的时候,得考虑清楚了。相关命令:接口配置模式下,mls qos trust  cos | ip-preference | dscp
配置了这些命令中的相关的命令后,说明设备就相信这个接口接收到的数据包中的COS值,IP 优先级,DSCP值。进入到设备内部后,就会按照默认的映射方式,映射到内部DSCP值。然后设备就会根据这个内部DSCP对数据流进行有条不紊的操作。
让我们再来看看,上面我们提到的这个命令中的参数。前面我们说了IP优先级和COS是一样的,为什么在这里都出来了呢?那肯定是有不同的地方啊。OK了,COS使用在2层,IP优先级用在3层。那么IP优先级和DSCP呢?他们好像也是一回事啊~~为什么也会同事出现了呢?那么有什么区别呢?这里之所以把他们俩个放在一起写出来了,是因为有的设备只支持IP优先级,而不认识DSCP,那么以DSCP来标示类的网络设备与之交流的时候,就会进行IP优先级和DSCP之间的映射,这个是非常简单的,只要把DSCP的后3位全部写成0OK 了。就可以实现DSCPIP优先级之间的完美映射了。
下面我们接着说,当设备信任了端口接收的数据中的DSCPCOSIP优先级,那么进来后就可以按照默认的映射来进行处理(处理行为在策略表中规定着呢)。那么我们是否可以让他们按照我们个人的意愿来进行映射呢,而不是默认的映射方式。答案是肯定的,我们完全可以根据网络应用需要将从某个端口进来的数据的DSCP映射到一个我们想要的内部DSCP值上去,就是利用命令:全局模式下,mls qos map cos-dscp  * * * * * * * *

其中的*号表示的是和COS对应的8位数字。搞清楚了是谁到谁的映射:是COSDSCP的映射,当然咯,后面的8位数表示的也是内部DSCP值。
以此类推,肯定也可以进行IP优先级到DSCP的映射咯mls qos map ip-prec-dscp [dscp-value]

 

下面,咱就讲讲如何根据数据包来进行分类,也就是那种基于ACL的。其实很简单,就是将我们建立好的ACL和要建立的CLASS关联起来。就这么简单,符合ACL的所有数据,我们就看做是一类。分类不是关键,关键是对他们进行更加精确和详细的控制------策略表。

 

 

具体实例:

 

1.全局配置模式下:class-map match-all  [name ]

                Match [……]括号里面就是具体的一些条件。(完善类表的过程)
这些条件根据不同的设备支持的QOS的特性的多少而有所差异。
2.全局配置模式:policy-map [name ]

                 Class [name]
                 ?                (完善策略表的过程)
就会显示这个设备支持的所有策略动作。
其中比较关键的还是第2中的第二个命令,它的作用就是把这个类表和策略表关联起来。
3将建立好的策略表应用到特性接口的出口或者进口的方向上。但是,并不是所有的交换机都支持出口策略的。命令:interface type slot/port
                          Service-policy {input | output }  [name]
4最后一个,也是最重要的一个:将该端口设置成信任端口。因为我们实施这些策略的动作的时候,人家是依据DSCP来的。如果是不信任这个接口来的DSCP的话,那么就无法进行这些策略动作了。

 

接下来要讲的就是最后一种了:NBAR----基于网络的应用识别。简单的说,这种分类方法,就是比上一种方法中的类表和策略表的定义方面,又多了一些参数,也就说功能更加完善了。基本步骤上面都是完全一样的。

 

到这里,我们就已经可以对数据进行详细分类了,各种方法都有。但是应用得具体情况,具体分析。

 

标记

这里需要各位朋友清楚的是:这个“标记”不是一个名词,而是一个动词。就是一个修改的动作。例如,我们对某个参数进行标记,那意思就说是我们我们对这个参数原来的数值进行了修改。
这个特性,可以让我们实现修改从某个特定的端口进来的数据包DSCP值,这样的话,就达到了我们对某些数据流进行特定服务的目的。我们可以认为在网络界确实有默认的一些应用和相应的DSCP的映射关系。但是,除了这些,我们还可以根据网络的具体环境人为的将一些我们特别关注的数据流打上一个我们自己想要打上的DSCP。并且,我们后面建立的CLASS—TABLEPOLICY—TABLE 中都要对这个DSCP值的数据包进行相应的操作设置。然后,这个值进去设备后,QOS就会根据这个DSCP而得到的内部DSCP对这些数据流进行一定的操作。这个就是QOS的标记特性。实现这个特性的命令是:在相应的接口下,使用
Mls qos dscp [dscp-value] 数值范围是0-----63

Mls qos cos  [cos-value] 数值范围是0------7

显然,这些得到的DSCP值或者COS值都不是QOS特性实施的依据-----内部DSCP,而是这些值经过映射后的DSCP值,叫做内部DSCP值。

 

如果,我们希望在通过ACL对通信流进行分类的策略映射表中配置标记。那么我们需要使用下列类别映射表操作命令:
Set ip dscp [ip-dscp-value]

Set ip precedence [ip –precedence-value]

Set cos [cos-value]

 

从文章的叙述布局上,我们就可以看的出:上面的那种在接口模式下强制改变进来的数据的DSCP值的方法和后面的这种软性的通过策略方法来实现改变数据的DSCP值是有点区别的。因为他们需要面向的对象的确定方式不同。前者,就可以精确到某个具体的端口的;而后者,面向的是那些分布在网络中各处的,但是具有同样的特定的数据(这个特点就是ACL来定的)

 

流量调节

在流量调节这方面,我们可以通过俩种方式来达到这种效果:一个是利用策略,一个是利用整型。
这俩种方式显然是并列的关系,中间也是存在着很多差距的。现在用最火的一个还是通过策略来进行流量的调节。并且,对于CISCO不同的设备,实现流量调节的方式也是不尽相同的。在CISCO路由器和交换机都支持策略和整型。只是支持和实现的方式不同。对于CISCO路由器来说,支持俩种整型方法:GTS(generic traffic shaping通用流量整型)FRTS(frame relay traffic shaping帧中继流量整型)。对于运行IOS软件的路由器,它使用CAR(committed access rate 承诺接入速率)工具来支持流量策略。而对于CISCO交换机支持流量策略和整型的方法和配置和路由器稍有不同。

 

其实,整型和策略机制都控制“通信流通过交换机传输的速度”,他们都使用分类来区分通信流,但是,他们之间还是有一些区别的。

 

整型测量通信流的速率(采用这种机制的时候,是需要由一个指定速率的),并推迟超额通信流的传输,确保通信流的速率不超过指定的值
所以呢,通过这种流整型量调节机制,可是实现那种突发的通信流量。这样呢,就可以减少交换机丢弃的数据了。其实说白了,这种调节机制的核心思想就是:通过测量数据流的速率,来确定哪些不合格的数据,并且推迟这些超越规定的通信流的传输时间。这样一来,也就是可以保证所有的这些数据都是可以传输出去的,但是付出的代价就是:延迟有可能会大大的增加。

所以呢,这种实现机制对与那种对延迟非常敏感的网络应用就非常的不好。

 

而策略对超过指定速率的通信流采取特性的措施,不再是推迟或者是缓冲通信流了。也就是说对于这种机制中,无论如何都不会以增加延迟作为代价的,而是对这些违规的数据流进行一些具体的处理措施。通常情况下,对于这种数据都是进行丢弃处理了,但是,我们现在可以使用其他的处理措施,比如信任或者标记。也就是说,我们又把这些数据流和灵活的策略结合在一起了,以后对这些不法分子处理起来就灵活的多了、、、、

 

因为策略可以支持很多的参数啊,比如速率啊,突发量啊,合规措施,超额措施,违规措施,

 

其中的参数,最难搞定的就是突发量了,所以我们这里给出了一个计算突发量的公式:
突发量=2 X RTT X 速率。其中,RTTTCP绘画的往返时间。这个参数的获得我们可以通过简单的命令ping 来获得。而速率是端到端的吞吐量。
CISCO交换机上,有3种类型的策略:
单一策略器:应用在单个接口上的策略器。

 

聚合策略器(aggregate policer :将策略参数应用到一组接口。是把这一组接口看做一个整体来运作的。例如,我们把一个限制流量速率不超过75M/S的聚合策略器运用到一组接口上,那么他所表达的意思就成为了:这组接口的总流量将不能超过75M/S。而单一策略器只可以运用到单个接口上。

 

微流策略(microflow policing ):它是针对单“个”(可以理解成是单种流)数据流的。交换机将策略参数应用于策略映射表中的每种类别。

 

通过上面的3种类别的策略器的描述,我们是不是觉得最后这个更好点啊~~~我觉得是,因为这个用起来更加灵活,并且也更加到位。其实呢,这3种策略器的实现都是要和类别映射表结合起来的。因为为了就是实现这个控制那些我们可以指定的那些数据流啊(就是我们打了标记的,分了类的)。实现策略器和有一定特点的数据流的结合。我们需要做的工作就有2:第一是定义、完善这些策略器的内容,第二是将这些除了器和类别流结合起来。

 

定义:全局配置模式下police [        ]  后面有很多的参数,到时候打个问号就好了,什么参数,及其解释就都出来了。一般也就是限制个速率啊,以及对违反这些规定的措施,比如说drop
关联:在策略映射表中,使用上以前定义的策略器就可以了。这个策略器,从整体上看,策略映射表就将其看作是一个处理动作。当然了,这个策略映射表中得包含着那个需要的分类表啊。否则,就不会完成映射了啊~~

 

这些都是非常简单的,他们运用起来的方式都是一样的,主要是明白他们之间的区别。

 

 

 

拥塞管理

拥塞管理是QOS一个非常重要的特性。后面的拥塞避免同样是。他们都是作用在出站口上的。我们使用QOS,就是为了让数据流按着我们的意思去走。或者快,或者慢,超出了我们设置的界限,该如何处理,是丢弃还是采取其他的一些比较温柔的处理措施。对于一个设备来说,数据有进有出,这个设备上出去的数据流,在另一个设备的角度上看,这就是进来的数据流,所以呢,我们要保证出去的这些数据流都是按着我们个人的意愿来走这个路的,至于到了对端的设备如何来处理这些进的数据,那是他们的事情。而我们现在要做的就是尽量的让我们这个设备上出去的数据更加如人意,争取做到数据流最大程度上传输顺畅,并且不给那个对端接受的设备带来太大的负担。

 

我们都知道,一个端口是包含多个队列的,包括输入队列和输出队列,并且每种队列都不是一个的。我们这个拥塞管理就是运用在这些输出对列上的。当数据进来的时候,是会被划分到不同的输出队列的。根据什么来分呢?为什么要区分开来呢?既然区分了,那又有什么不一样的处理措施呢?这些问题,是我们知道了这个特性是运用在端口上的,还是具体到端口的各个输出队列上的时候我们必须想到的。带着这些疑问,我们来详解。

 

 

在默认的情况下呢,也就是没有使用QOS特性的时候,交换机的各个端口中的各个队列对待所有的数据都是一视同仁的,在一个接口中使用的派对方法是:FIFO,先进先出。就是说谁来的早就先解决谁。是有先来后到的这么一说的。看起来,挺合理啊。但是,当今社会那里有这么“公平”的事情啊,不都是“老大”说了算的吗?呵呵、、这里的老大就是指的那种老大的身份,谁的地位高,谁就说了算,就先解决谁的问题。

 

 

那既然出现了这种不公平的问题,肯定得是有身份依据的。不同身份的数据分配到不同的输出队列。这样一来,我们可以肯定的是:这个特性使得有依据来区分各个队列,并且还可以把不同身份的数据安排到特定的队列中,这不就是特定DSCP值的数据分配到特定的队列吗?嘿嘿、、、、这是我们的猜测。我们必须得这样,得先有自己的想法,然后戴着你个人的这些想法去看书,或者是和作者的想法一致,或者是撞击出智慧的火花,对我们来说都是另外的一种收获,我们记忆知识还会更牢固。

 

来区分队列:
不同型号的交换机的端口支持的队列是不一样的,有支持3个的,4个的,甚至2个的。并且他们在没使用QOS的时候,身份还是一样的。即使他们这些队列中有几个个别的队列的骨子里有中特别的气质,哎、、、、但是外界条件不允许啊~~没办法,也只能是蓝领一个啊。但是当我们启用了这个QOS特性后,启用了端口队列的优先级后,那些有着内在气质的队列,就可以鹤立鸡群了。与众不同!默认情况下,内在的气质是与生俱来的,只要我们启用了这个端口队列的优先级特性,某些队列就成了优先级队列,在这个队列里排队的数据都是优先处理的,只有当这个队列中的数据处理完了,其他的队列的数据才开始进行处理。所以呢,以后我们就可以把一些情况比较紧急的数据放进这个队列里,当然了,这个问题就牵涉到了后面的特性身份的是数据和队列的映射问题了。OK,这是默认的情况下,但是呢,气质呢是可以后天培养的,所以我们也可以对平常的那些队列进行特性的培养啊,使我们心仪的队列成为优先级队列,而不是使用默认的优先级队列了。也就说,这个优先级队列的指定的操作性还是很大的嘛,嘿嘿、、、、具体的实现命令是这样的:

 

使用默认的优先级队列:
端口模式下:priorityqueue out cisco 3500系列,默认的是队列4

不同型号的设备的配置命令是不同的。

使用后天形成的优先级队列:
wrrqueue   priorityqueue

wrrqueue   cosmap    [queue id ]    [threshold 阀值]   [cos value ….]

 

其中这个阀值是什么意思,我到现在还真的不是很了解,因为对应着一个队列可以有好几个阀值。非常不解。后面的COS说的是出站COS。而不是内部DSCP

 

通过使用这个命令,我们就可以将一定COS值的数据映射到特定的队列中,并且这个队列也就是我们说的那个后天形成的优先级队列。

 

通过这几条简单命令的阐述,我们把上面说的俩个问题都解决了:队列的区分和队列与特定数据流的映射。

 

我们都知道,QOS对数据包进行特定处理的依据是内部DSCP。我们外面进来的数据DSCP在端口的时候有可能被重改写(相关的命令前面已经提到过)或者是通过策略表中的动作来实现DSCP的更改。所以呢,我们称这个状态下的DSCP值(对于2层的数据来说就是COS,对于3层的来说就是IP优先级)为外部DSCP,即使被更改了。这个数值到了交换机的内部后,还得进行一次映射,即:COS/IP优先级到内部DSCPQOS特性处理数据的依据)的映射。这个映射表呢我们也是可以尽心改变的,在前面似乎已经提到了相关的配置命令。当然了,这样说,那么肯定就会存在一个默认的映射关系表啊!最后的时候,如果时间允许我会尽量的给大家画出来。我们一直在强调这个问题:这个内部DSCP只是在内部的时候使用的。

 

上面,我们对命令的参数进行了一定程度上的解释,这里主要的就是那个后面的COS值,这个值说的是出站COS,而不是内部DSCP值。出站是根据这个出站COS来对数据进行传输处理的。看来,这里还有一个内部DSCP到出站COS的映射过程。肯定的啦,存在一个默认的映射关系表的,并且呢,我们也是可以人为的改变这种映射关系的。

 

相关的配置命令:
Mls qos map dscp—cos [dscp value ] to [ cos value]

 

 

我们现在是,可以区分数据了,可以区分不同的队列了,也可以区分把这些数据有区别的映射到不同的队列上了,那接下来的问题就是最关系的问题了:对各个队列的处理又是怎样的呢?

 

我们可以对各个出站队列设置的特定的监测参数,以及一个特定的阀值。比如为各个队列指定一定的带宽,后面具体的参数的取值范围是1----255。再比如队列长度,参数的具体取值范围是1%---100%。这些监测参数说明:我给你相应方面的资源就这些(是对各个队列而言的)

 

端口配置模式下:
Wrr-queue bandwidth [weight for queue1] [weight for queue 2] …..[weight for queue n]

Wrr-queue queue-limit [low priority queue weight ] [medium priority queue weight] [high priority queue weight ]

在这里,第二个命令中,大家都看到了出现了低级队列,中级队列和高级队列的说法。其实,
在端口的队列中确实有这么一种说法的:队列1属于低级队列,队列2数据高级队列,再往上就是属于严格优先级队列了。所谓的严格优先级队列就是我们说的那个优先级队列。不管是人为指定的,还是那个默认的。我们都叫它严格优先级队列。
但是如果这些分配个各个队列的资源都快用光了或者都用光了咋办啊?当然是产生拥塞了啊,这些是我们最大的忌讳啊~~~咋办呢?这就是拥塞避免的事情了。

 

 

 

拥塞避免

 

简单来讲,快拥塞的时候的一般的处理措施当然就是丢弃后来的那些数据咯,但是如果后面来的那些数据还是非常的重要的,那怎么办呢?我们首要的原则就是为了保证这些重要的应用顺利实现嘛,所以,我们丢弃后来的这些数据包的时候就得有一定的选择了啊,

 

具体的配置命令如下:

 

Wrr-queue random-detect min-threshold [queue id ] [thr m%]

Wrr-queue random-detect max-threshold [queue id ] [thr n%]

 

 

这俩个命令也就说:当相应的id的队列中的数据填满程度达到了该队列的m%时,开始进行丢弃这个队列的数据。当达到n%的时候就开始采取尾丢弃的方法,也就说说达到这个程度,这个接口的在接受到的任何一个数据包都进行丢弃。

 

总结一下:

 

其实,说白了,QOS就是保证数据经过的每一个环节都可以得到人为的精确控制。通过什么来实现啊,还是得说那个内部DSCP。但是这个东西是用在设备内部的。

 

那咱就看看,整个数据传输的过程中,有过几次外部的DSCP(COS或者IP优先级)和内部DSCP的映射。

 

1.  进设备端口的时候,得需要给数据加上一个,为什么啊,为的就是让这些数据能有一个COS或者IP优先级好和内部的DSCP映射啊,然后通过这个东西对数据进行分类啊啥的,就是为了得到一个可以对这些数据进行区别对待的依据。
2.  出设备的时候,我们还需要把内部的DSCP映射到COS,它叫做出站COS,为的就是实现拥塞的管理。因为拥塞这家伙就靠这个活着呢。

 

搞清楚了这么个流程,中间的那些具体的处理措施啊,就简单多了。

 

大家有没有觉得拥塞管理和拥塞避免与流量调节有点别扭啊?我开始看起来的时候,就总觉得他们在说一回事,有点犯迷糊,呵呵、、、其实,你了解了数据在端端之间的经过的每一个坑吭砍砍的就知道了,他们说的不是一回事,真都不是一回事,呵呵、、、、、考虑考虑!!

 

凌晨2点,整理完毕,有点多,大家慢慢的看,仔细的看。希望对大家有所帮助。

中间如果出现什么问题,还请大家多多指正~~谢谢!我会继续努力,争取写出更好的文章。

QQ418838267           Email[email]xuhuigang2004@126.com[/email]

 

大家有什么想法可以和我交流,让我们共同进步。

 

不好意思,差点忘记了,我还得给大家写上上述文章中设计到的映射表。

 

默认的映射关系表:

 

COS到内部DSCP的映射关系表

COS

0
1
2
3
4
5
6
7
内部DSCP

0
8
16
24
32
40
48
56

 

IP优先级到内部DSCP的映射关系表

IP优先级

0
1
2
3
4
5
6
7
内部DSCP

0
8
16
24
32
40
48
56

 

内部DSCPCOS的映射关系表

内部DSCP

0~7
8~15
16~23
24~31
32~39
40~47
48~55
56~63
COS

0
1
2
3
4
5
6
7

 

 

0

收藏

mycdsee

19篇文章,6W+人气,0粉丝

Ctrl+Enter 发布

发布

取消

f92360e227f9d91cdff7ea95120630ef.png
left-qr.jpg

扫一扫,领取大礼包

0

分享
qr-url?url=https%3A%2F%2Fblog.51cto.com%2Fmycdsee%2F123740
mycdsee
noavatar_middle.gif