异步传输模式 (ATM) : IP to ATM 业务类别

了解 ATM 上基于类的加权公平排队

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 22 日) | 反馈


目录


简介

使用基于类的加权公平排队(CBWFQ)技术,本文提供一介绍给数据流排队。

加权公平排队(WFQ)使慢速链路,例如串行链路,为所有流量类型提供公平处理。它分类流量到根据层三和层四信息(亦称会话)的不同的流,例如IP地址和TCP端口。它执行此,无需要求您定义访问列表。这意味着低带宽流量有效有在高带宽数据流的优先级,因为高带宽数据流以其分配的权值的比例共享传输介质。然而, WFQ有某些限制:

  • 如果流的总数显著地,增加它不可扩展。

  • Native WFQ不是可用的在高速接口例如ATM接口。

CBWFQ提供一解决方案给这些限制。不同于标准的WFQ, CBWFQ允许您定义数据流类别和运用参数,例如带宽和队列极限,对这些类。您分配到类的带宽用于计算“权重”该类。匹配类标准的重要性每数据包从此也计算。WFQ应用对能包括几个流)的类(而不是流。

关于配置CBWFQ的更多信息,请点击以下链路:

排队(每个vc CBWFQ)在Cisco 7200、3600及2600路由器的基于类的每VC加权公平排队。

排队在基于RSP的平台的基于类的每VC加权公平排队。

开始使用前

规则

有关文档规则的详细信息,请参阅 Cisco 技术提示规则

先决条件

本文档没有任何特定的前提条件。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备创建的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您是在真实网络上操作,请确保您在使用任何命令前已经了解其潜在影响。

网络图

为了说明WFQ如何工作,请使用以下设置:

/image/gif/paws/10406/wfq_illustrated.gif

在我们使用得这里的设置,数据包能在以下两个队列之一中存储:

  • 在端口适配器和网络模块的硬件先入先出(FIFO)队列。

  • 队列在Cisco IOS�软件里(在路由器输入/输出[I/O]内存)服务质量(QoS)功能例如CBWFQ可以应用的地方。

在他们被分段到发射的前,信元在端口适配器的FIFO队列存储数据包。当此队列满时,端口适配器或网络模块表明对IOS软件队列拥塞。此机制呼叫反压。在接收此信号,路由器在IOS软件里停止发送数据包到接口FIFO队列并且储存数据包,直到队列不再拥挤。当数据包在IOS时存储,系统能应用QoS功能例如CBWFQ。

设置传输环路限制

一问题用此排队机制是,越大在接口的FIFO队列,越长在数据包前的延迟在此队列结束时能传送。这能引起延迟敏感数据流的严重性能问题例如语音流量。

tx-ring-limit命令的永久虚拟电路(PVC)使您减少FIFO队列的大小。

interface ATMx/y.z point-to-point
      ip address a.b.c.d M.M.M.M
      PVC A/B 
       TX-ring-limit 
       service-policy output test

限制您能指定此处的(x)是一定数量的数据包(Cisco 2600及3600路由器)或数量微粒(Cisco 7200及7500路由器)。

减少传输环路的大小有两个好处:

  • 它在FIFO队列减少时间数据包等待在被分段前。

  • 它在IOS软件里促进使用QoS。

传输环路限制的影响

请查看传输环路限制的影响使用在上面我们的网络图中表示的设置。我们能假设以下:

  • 数据流生成器发送流量(1500个字节信息包)到接收器设备,并且此流量超载在router1和router2之间的PVC 0/102。

  • Router3设法ping router1。

  • CBWFQ在路由器2.启用。

现在请查看两配置使用不同的传输环路限制为了发现这有的影响。

示例 A

在本例中,我们设置传输环路到三(Tx ring limit=3)。这是什么我们看到,当我们ping从router3时的router1。

POUND#ping ip
     Target IP address: 6.6.6.6
     Repeat count [5]: 100000
     Datagram size [100]: 
     Timeout in seconds [2]: 
     Extended commands [n]: 
     Sweep range of sizes [n]: 
     Type escape sequence to abort.
     Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![snip]
     Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms

示例 B

在本例中,我们设置传输环路到40 (Tx ring limit=40)。这是什么我们看到,当我们在示例回答:时使用ping和一样

POUND#ping ip
     Target IP address: 6.6.6.6
     Repeat count [5]: 10000
     Datagram size [100]: 36
     Timeout in seconds [2]: 10
     Extended commands [n]: 
     Sweep range of sizes [n]: 
     Type escape sequence to abort.
     Sending 10000, 36-byte ICMP Echos to 6.6.6.6, timeout is 10 seconds:
     !!!!!!!!!!!!.
     Success rate is 92 percent (12/13), round-trip min/avg/max = 6028/6350/6488

正如您上面看到的越大传输环路限制,越大ping Round-Trip Time (RTT)。我们能从此推导一个大传输环路限制在传输中可能导致明显的延迟。

CBWFQ 如何工作

即然我们看到硬件FIFO队列的大小的影响,请正确地发现CBWFQ如何工作。

Native WFQ分配重要性到每次会话,然后安排不同的流的每数据包的传输时期。权重是每个流IP优先级的功能,并且调度时间取决于数据包大小。欲了解更详细的信息点击此处在WFQ。

CBWFQ分配重要性到每个配置的等级而不是每个流。此权重与为每类配置的带宽是按比例。精密地,权重是类带宽划分的接口带宽的功能。所以,越大带宽参数,越小权重。

使用以下公式,我们能计算数据包调度时间:

scheduling tail_time= queue_tail_time + pktsize * weight 

总接口带宽划分

请查看路由器如何划分区别类之间的总接口带宽。为了服务类,路由器使用日历队列。这些日历队列中的每一存储必须传送在同样scheduling_tail_time的数据包。路由器然后服务这些日历队列一次一个。请查看此进程:

  1. 如果拥塞在端口适配器出现,当数据包在输出接口时到达,这的IOS (CBWFQ导致队列在这种情况下)。

  2. 路由器在日历队列计算此到达数据包的调度时间并且储存它与此调度时间相应。仅每类一数据包在特定的日历队列可以存储。

  3. 当是时间服务数据包存储的日历队列时, IOS清空此队列并且发送数据包对在端口适配器的FIFO队列。描述的传输环路限制取决于大小此FIFO队列以上

  4. 如果FIFO队列太小以至于不能适合在被服务的日历队列保持的所有数据包,路由器在达成协议的日历队列重新安排不可能存储在下调度时间的数据包(与他们的权重相应)并且安置他们。

  5. 当所有这执行时,端口适配器对待在其FIFO队列的数据包并且发送在电线的信元,并且IOS移动向下日历队列。

    幸亏此机制,每类统计上接收接口带宽的部分与为它配置的参数相应。

日历队列机制与传输环大小

请查看日历队列机制和传输环大小之间的关系。一条小传输环路允许QoS迅速启动并且减少等待的数据包的延迟传送(对延迟敏感数据流是重要例如语音)。然而,如果太小,它能导致某些类的吞吐量降低。这是因为很多数据包可能必须重新安排,如果传输环路不能适应他们。

有,不幸地,传输环大小的没有理想值,并且查找最好的值的唯一方法是通过试验。

带宽共享

我们能查看共享使用设置的带宽的概念表示在我们的网络图中,上述。信息包生成器导致不同的流并且发送他们到接收器设备。这些流代表的数据流总量是超载PVC的足够。我们实现在Router2的CBWFQ。这是什么我们的配置看上去象:

access-list 101 permit ip host 7.0.0.200 any 
   access-list 101 permit ip host 7.0.0.201 any 
   access-list 102 permit ip host 7.0.0.1 any 
   ! 
   class-map small 
     match access-group 101 
   class-map big 
     match access-group 102
   !
   policy-map test
   policy-map test 
     small class 
      bandwidth <x>
     big class 
      bandwidth <y>
    interface atm 4/0.102 
     pvc 0/102 
       TX-ring-limit 3 
       service-policy output test 
       vbr-nrt 64000 64000

在我们的示例中, Router2是Cisco 7200路由器。这是重要,因为传输环路限制用微粒表示,不是数据包。数据包在端口适配器FIFO队列排队,当空闲点是可用的,即使超过一个微粒是需要的存储数据包。

什么是微粒?

而不是分配连续内存一件缓冲区的,微粒缓冲分配内存离散(分散的)片段,呼叫微粒,一起然后连接他们形成一逻辑数据包缓冲。这呼叫微粒缓冲。在这样方案,数据包可能在多个微粒间然后被涂。

在7200路由器中我们使用得这里,微粒大小是512个字节。

我们能验证是否Cisco 7200路由器通过使用show buffers命令的使用微粒:

router2#show buffers
     [snip]
     Private particle pools: 
     FastEthernet0/0 buffers, 512 bytes (total 400, permanent 400):
          0 in free list (0 min, 400 max allowed)
          400 hits, 0 fallbacks
          400 max cache size, 271 in cache
     ATM4/0 buffers, 512 bytes (total 400, permanent 400): 
          0 in free list (0 min, 400 max allowed)
          400 hits, 0 fallbacks
          400 max cache size, 0 in cache

测试 A

“斯莫尔”和“我们使用此测验的大”类接下来填充:

  • 小类-我们配置带宽参数对32 Kbps。此类存储十数据包从7.0.0.200的1500个字节,跟随由十数据包从7.0.0.201的1500个字节

  • 大型组-我们配置带宽参数对16 Kbps。此类存储十1500字节数据包一个流从7.0.0.1的。

数据流生成器发送为接收器设备注定的突发数据流在100 Mbps对在下列顺序的Router2 :

  1. 从7.0.0.1的十数据包。

  2. 从7.0.0.200的十数据包。

  3. 从7.0.0.201的十数据包。

验证流权重

请查看重要性应用对不同的流。要执行此,我们能使用show queue ATM x/y.z命令

alcazaba#show queue ATM 4/0.102 
     Interface ATM4/0.102 VC 0/102 
     Queueing strategy: weighted fair 
     Total output drops per VC: 0 
     Output queue: 9/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated) 

  (depth/weight/total drops/no-buffer drops/interleaves) 7/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 2/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

当从7.0.0.200的所有数据包排队在路由器外面时,我们能看到以下:

alcazaba#show queue ATM 4/0.102 
     Interface ATM4/0.102 VC 0/102 
     Queueing strategy: weighted fair 
     Total output drops per VC: 0 
     Output queue: 9/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated)
 
  (depth/weight/total drops/no-buffer drops/interleaves) 7/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255
  
  (depth/weight/total drops/no-buffer drops/interleaves) 2/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

正如您上面看到的从7.0.0.200和7.0.0.201的流有同一重要性(128)。此权重是半的重要性的大小分配到从7.0.0.1 (256)的流。这对应于事实我们的小类带宽两次是大小我们的大型组。

验证带宽分配

因此如何能验证区别流之间的带宽分配?FIFO排队方法用于每类。我们的小类充满十数据包从一流和十数据包从第二个流。一流从在32 Kbps的小类删除。当他们发送,从另一个流的十数据包被发送。同时,从我们的大型组的数据包删除在16 Kbps。

我们能看到,因为数据流生成器发送突发流量在100 Mbps,将超载PVC。然而,尽管没有在PVC的流量,当测验开始,因为从7.0.0.1的数据包是到达路由器的第一个,从7.0.0.1的一些数据包将发送,在CBWFQ开始由于拥塞前(换句话说,在传输环路全双工)前。

因为微粒大小是512个字节,并且传输环大小是三个微粒,我们能看到从7.0.0.1的两数据包被发送,在拥塞出现前。一在电线立即发送,并且第二在形成端口适配器FIFO队列的三个微粒存储。

我们在能看到下面调试是路由器)的接收器设备(:

Nov 13 12:19:34.216: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, len 1482, rcvd 4 
   Nov 13 12:19:34.428: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 

   
!--- congestion occurs here.


   Nov 13 12:19:34.640: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:34.856: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.068: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.280: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.496: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.708: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.920: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.136: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.348: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.560: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.988: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.200: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.416: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.628: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.840: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.056: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.268: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.480: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.696: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.908: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.136: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.348: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.560: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.776: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.988: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:40.200: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:40.416: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4  

因为两个流的数据包大小是相同的,根据调度时间公式,我们应该为从我们的大型组的每数据包看到从我们的发送的小类的两数据包。这正确地是什么我们在上面调试看到。

测试 B

对于我们的第二测验,请接下来填充类:

  • 小类-我们配置带宽参数对32 Kbps。十数据包从7.0.0.200的500个字节由十数据包从7.0.0.201的1500个字节生成,跟随。

  • 大型组-我们配置带宽参数对16 Kbps。类存储来自7.0.0.1的1500个字节信息包一个流。

数据流生成器发送突发数据流在100 Mbps对在下列顺序的Router2 :

  1. 从7.0.0.1的十1500字节数据包。

  2. 从7.0.0.200的十500-byte数据包。

  3. 从7.0.0.201的十1500个字节信息包。

FIFO在每类配置。

验证流权重

下一步是验证重要性应用对分级流:

alcazaba#show queue ATM 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queueing strategy: weighted fair 
   Total output drops per VC: 0 
   Output queue: 23/512/64/0 (size/max total/threshold/drops) 
      Conversations  2/3/16 (active/max active/max total)  
      Reserved Conversations 2/2 (allocated/max allocated)  

  (depth/weight/total drops/no-buffer drops/interleaves) 15/128/0/0/0    
     Conversation 25, linktype: ip, length: 494 
     source: 7.0.0.200, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 8/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255 

   alcazaba#show queue ATM 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queueing strategy: weighted fair 
   Total output drops per VC: 0 
   Output queue: 13/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated)  

  (depth/weight/total drops/no-buffer drops/interleaves) 8/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 5/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63,

正如你在以上输出看到,从7.0.0.200和7.0.0.201的流接收同一重要性(128)。此权重是半的重要性的大小分配到从7.0.0.1的流。这对应于事实小类两次有一个带宽大小我们的大型组。

验证带宽分配

我们能由接收器设备导致以下调试:

Nov 14 06:52:01.761: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:01.973: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 

   
!--- Congestion occurs here.
 

   Nov 14 06:52:02.049: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.121: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.193: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.269: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.341: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.413: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.629: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:02.701: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.773: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.849: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.921: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:03.149: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.361: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.572: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.788: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.000: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.212: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.428: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.640: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.852: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.068: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.280: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.492: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.708: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.920: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.132: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.348: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.560: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

在此方案中,在我们的小类的流没有同一数据包大小。因此,数据包分布为测验A不是一样琐细象,上述。

调度时间

请有仔细观察在每数据包的调度时间。使用以下公式,数据包的调度时间计算:

scheduling tail_time= sub_queue_tail_time + pktsize *
     weight

对于不同数据包大小,调度时间使用以下公式:

500 bytes (small class): scheduling tail_time = x + 494 * 128
     = x + 63232 
     1500 bytes (small class): scheduling tail_time = x + 1494 *
     128 = x + 191232 
     1500 bytes (big class): scheduling tail_time = x + 1494 *
     256 = x + 382464

从这些公式,我们能看到六数据包从我们的小类的500个字节为每数据包从我们的大型组的1500个字节传送(显示在以上的debug输出中)。

我们能也看到两数据包从我们的小类的1500个字节为一数据包从我们的大型组的1500个字节发送(显示在以上的debug输出中)。

从以上我们的测验,我们能推断以下:

  • 传输环路的大小(tx-ring-limit)确定多排队机制快开始工作。当传输环路限制增加时,我们能随着ping RTT的增加看到影响。因此,如果实现CBWFQ或低延迟队列[LLQ]),请考虑降低传输环路限制。

  • CBWFQ允许一般共享区别类之间的接口带宽。

相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


相关信息


Document ID: 10406