Modo de transferencia asíncrona (ATM) : Clase de servicio IP a ATM

Introducción a Weighted Fair Queuing en ATM

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento proporciona una introducción al envío a cola de tráfico que utiliza la tecnología del Espera equitativa ponderada (WFQ).

El WFQ fue introducido para permitir a los links de velocidad lenta, tales como links seriales para proporcionar el tratamiento justo para todos los tipos de tráfico. Para hacer esto, el WFQ clasifica el tráfico en diversos flujos (también conocidos como conversaciones) basó en la información de la capa tres y de la capa cuatro, tal como IP Addresses y puertos TCP. Hace esto sin el requisito de usted de definir las Listas de acceso. Esto significa que el tráfico del ancho de banda baja tiene con eficacia prioridad sobre el tráfico de ancho de banda alto porque el tráfico de ancho de banda alto comparte los medios de transmisión en proporción a su peso asociado.

Pero, el WFQ tiene ciertas limitaciones:

  • No hay posibilidad de ampliación si la cantidad de flujo aumenta considerablemente.

  • WFQ nativo no está disponible en interfaces de alta velocidad como las interfaces ATM.

Class-based weighted fair queuing (CBWFQ) provee una solución para estas limitaciones.

A diferencia de WFQ estándar, CBWFQ le permite definir clases de tráfico. Usted puede también aplicar los parámetros, tales como ancho de banda y límites de cola, a ellos. El ancho de banda que usted asigna a una clase se utiliza para calcular la ponderación de esa clase. A partir de esto, también se calcula el peso de cada paquete que coincide con los criterios de clase. El WFQ entonces se aplica a las clases, que pueden incluir varios flujos, bastante que los flujos ellos mismos.

Refiera a estos documentos para más información sobre cómo configurar el CBWFQ:

Las interfaces ATM no soportan el flujo basado nativo WFQ configurado directamente en una interfaz con el comando fair-queue. Pero, con el software que soporta el CBWFQ, usted puede configurar el flujo basado WFQ dentro de la clase predeterminada, tal y como se muestra en de este ejemplo:

policy-map test
 class class-default
  fair-queue
!         
interface ATMx/y.z point-to-point
 ip address a.b.c.d M.M.M.M
 pvc A/B 
  service-policy output test

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Diagrama de la red

Utilice esta configuración para ilustrar cómo el WFQ trabaja:

/image/gif/paws/10049/wfq_illustrated.gif

En esta configuración, los paquetes se pueden salvar en una de estas dos colas de administración del tráfico:

  • La cola del Primero en entrar, primero en salir (FIFO) del hardware en el adaptador y el módulo de red del puerto

  • La cola en el software del½ del¿Â del Cisco IOSïÂ, en la memoria del [I/O] de la entrada-salida del router, donde las características del Calidad de Servicio (QoS) tales como CBWFQ pueden ser aplicadas

La cola FIFO en el adaptador del puerto guarda los paquetes antes de que éstos sean segmentados en celdas para su transmisión. Cuando esta cola está completa, el módulo de red o adaptador del puerto le indica al software del IOS que la cola está congestionada. El mecanismo se llama contrapresión. En el recibo de esta señal, el router para enviar los paquetes a la cola primero en entrar, primero en salir de la interfaz y salva los paquetes en el software IOS hasta que la cola sea uncongested otra vez. Cuando los paquetes se salvan en el IOS, el sistema puede aplicar QoS.

Cómo establecer el límite del anillo de transmisión

Un problema de este mecanismo de almacenamiento en cola es que cuanto más grande es la cola FIFO en la interfaz, más prolongada puede ser la demora antes de transmitir los paquetes al final de esta cola. Esto puede producir problemas graves de rendimiento en el tráfico sensible al retardo como el tráfico de voz.

El comando tx-ring-limit del circuito virtual permanente (PVC) le permite reducir el tamaño de la cola FIFO.

interface ATMx/y.z point-to-point
 ip address a.b.c.d M.M.M.M
 PVC A/B 
  tx-ring-limit <size>

  service-policy output test

El <size> que usted puede especificar aquí es varios paquetes, para los Cisco 2600 y 3600 Router, o cantidad de partículas, para los Cisco 7200 y 7500 Router.

La reducción del tamaño del anillo de transmisión tiene dos ventajas:

  • Reduce la cantidad de tiempo de los paquetes espera en la cola primero en entrar, primero en salir antes de que se divida en segmentos.

  • Acelera el uso de QoS en el software IOS.

Impacto del límite del anillo de transmisión

Mire el impacto del límite del anillo de transmisión que utiliza la configuración mostrada en el diagrama de la red anterior. Asuma éstos:

  • El generador de tráfico envía el tráfico (1500 paquetes de bytes) al dispositivo del fregadero, y este tráfico sobrecarga el PVC 0/102 entre el router1 y el router2.

  • El router 3 intenta hacer un ping al router 1.

  • WFQ está habilitado en el router2.

Mire dos configuraciones que utiliza diversos límites del anillo de transmisión para ver que el impacto que esto tiene.

Ejemplo A:

En este ejemplo, usted fijó el anillo de transmisión a tres (tx-ring-limit=3). Esto es lo que usted ve cuando usted hace ping el router1 del router3:

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   

router2#show queue atm 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queuing strategy: weighted fair 
   Total output drops per VC: 1505772 
   Output queue: 65/512/64/1505772 (size/max total/threshold/drops) 
    Conversations  2/3/16 (active/max active/max total)    
    Reserved Conversations 0/0 (allocated/max allocated)    

(depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0    
   Conversation 2, linktype: ip, length: 58 
   source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1  
   
!--- ping 
   

(depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0    
   Conversation 15, linktype: ip, length: 1494 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255 
   
!--- This is traffic from the traffic generator. 

Ejemplo B

En este ejemplo, usted fijó el anillo de transmisión a 40 (tx-ring-limit=40). Esto es lo que usted ve cuando usted utiliza el mismo ping que en el ejemplo A:

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 ms

Como se puede observar, si el límite de tono de transmisión es mayor, mayor será el tiempo que insumirá el trayecto de ida y vuelta del ping (RTT). Usted puede deducir de esto que un límite del anillo de transmisión grande puede llevar a los retrasos importantes en la transmisión.

Cómo calcular la ponderación

En la cola ATM de la demostración hecha salir en el ejemplo A, usted ve que una ponderación está asignada a cada conversación. Mire esto más detalladamente:

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

(depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0    
   Conversation 2, linktype: ip, length: 58 
   source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1    

(depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0    
   Conversation 15, linktype: ip, length: 1494 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

Cuando usted utiliza el WFQ, usted puede calcular la ponderación de cada conversación con el uso de esta fórmula:

  • weight=32384/(precedence+1) - para el Cisco IOS Software Release 12.0(5)T y Posterior.

  • weight=4096/(precedence+1) - para las versiones de Cisco IOS Software antes de 12.0(5)T.

Cómo calcular el horario de programación

Usted puede ahora utilizar estas ponderaciones para calcular el horario de programación de cada paquete, cuando el paquete se remite de la cola IOS a la cola primero en entrar, primero en salir del adaptador o del módulo de red del puerto.

Usted puede calcular el horario de programación de salida con el uso de esta fórmula, donde está el horario de programación el queue_tail_time actual:

tiempo de programación de salida = queue_tail_time + pktsize*weight

Cómo funciona WFQ

Esta sección explica cómo el WFQ trabaja. El principio de WFQ es que los paquetes con una pequeña ponderación, o los pequeños paquetes, deben conseguir la prioridad cuando se envían.

Cree un flujo que comprenda los paquetes grandes de los diez paquetes y cuatro paquetes más pequeños (de 82 bytes) esos utilizan un generador de tráfico para verificar esto.

En este ejemplo, el router2 es un Cisco 7200 Router con un PA-A3 (adaptador de puerto ATM). Esto es importante porque el tamaño de la cola primero en entrar, primero en salir de la salida en el adaptador del puerto se expresa en las partículas y no en los paquetes. ¿Vea cuál es una partícula? sección para más información.

¿Qué es una partícula?

En vez de la asignación de la una pieza de memoria contigua para un buffer, el mitigar de la partícula afecta un aparato los pedazos (dispersados) discontiguous de memoria, llamados las partículas, y después los conecta juntos para formar un almacén intermedio del paquete lógico. A esto se lo llama memoria intermedia de partículas. En tal esquema, un paquete puede esparcirse en partículas múltiples.

En el 7200 Router, el tamaño de partícula es 512 bytes.

Utilice el comando show buffers para verificar si los Cisco 7200 Router utilizan las partículas:

router#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
ATM2/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

Test A

Éstas son algunas pruebas para ilustrar la funcionalidad WFQ. En esta primera prueba, mire si el ancho de banda se puede compartir entre diversas conversaciones.

En esta prueba, usted hizo que el generador de tráfico envía el tráfico rápidamente bastante para sobrecargar el PVC 0/102 entre el router1 y el router2. Realice un ping del router3 al router1 a través del mismo PVC:

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:
......... (WFQ is enabled here)!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.[break]
Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms

Como usted puede ver de la salida mostrada, hasta que el WFQ se habilite en la interfaz, el tráfico evita que el otro tráfico vaya a través y muere de hambre la línea. Tan pronto como la WFQ se habilita, el ping es exitoso.

Usted puede ver del que, con el uso del WFQ, el ancho de banda se pueda compartir entre diversas conversaciones sin una que bloquea las otras.

Test B

Éste es cómo se comparte el ancho de banda.

El flujo que el generador de tráfico envía es una explosión integrada por diez paquetes grandes, seguido por cuatro paquetes más pequeños de 82 bytes. Usted envía esto en el 100 Mbps al router2. Cuando usted envía la explosión, la cola de salida en la interfaz ATM del router2 está vacía. El router2 envía estos paquetes a través de 10 KB PVC (esto es un PVC muy lento) para asegurarse de que la congestión ocurre en la cola de salida.

Conduzca esta prueba en varias etapas para simplificar este proceso:

Etapa 1

El tráfico grande comprende diez paquetes de 482 bytes. Como las partículas en PA-A3 son 512 bytes, cada paquete, ya sea grande o pequeño, debe tomar una partícula cuando se lo almacena en la cola de salida del adaptador de puerto. El límite del anillo de transmisión del router es tres (tx-ring-limit=3). Éste es un ejemplo de lo que usted puede ver en el dispositivo del fregadero:

   .Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, len 482, rcvd 4 
   .Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 

   
!--- Congestion occurs at this point. 


   .Nov  7 15:39:15.512: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.516: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:17.816: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:17.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 

Usted puede ver los cuatro paquetes de 482 bytes enviados antes de los paquetes 82-byte, que deben conseguir normalmente la prioridad. Esta es la razón por la cual esto sucede.

Dado que la ráfaga se compone principalmente de diez paquetes de 482 bytes, éstos llegan primero al router, seguidos por los paquetes de 82 bytes. Puesto que llegan los paquetes del 482-byte en un momento en que no hay congestión, pues no hay tráfico, un paquete se hace cola inmediatamente al Segmentation And Reassembly del adaptador del puerto (SAR) que se chunked en las células y enviado encendido el alambre. En otras palabras, el anillo de transmisión continúa vacío.

Usted puede calcular que el tiempo necesario enviar un paquete del 482-byte es mayor que la época necesaria para el generador de tráfico para enviar la explosión total. Usted puede por lo tanto asumir que, cuando el primer paquete del 482-byte se hace cola al adaptador del puerto, más paquetes del 482-byte de la explosión están ya presentes en el router. Por lo tanto, se pueden enviar a la cola del anillo de transmisión más paquetes de 482 bytes. Tres más paquetes de 482 bytes se hacen cola con el uso de las tres partículas libres presentes allí.

Nota: Los paquetes se ponen en cola en el anillo de transmisión ni bien hay una partícula libre, incluso si necesitan más de una partícula para almacenarse.

En este momento, hay congestión, puesto que las tres partículas son llenas. Entonces, se inicia el almacenamiento en cola en el IOS. Cuando los cuatro paquetes 82-byte finalmente alcanzan al router, hay congestión. Estos cuatro paquetes se colocan en la cola y se utiliza WFQ en los dos flujos. Mire la cola atmósfera que utiliza el comando show queue atm para ver esto:

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

(depth/weight/total drops/no-buffer drops/interleaves) 4/32384/0/0/0    
   Conversation 6, linktype: ip, length: 82 
   source: 7.0.0.200, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255    

(depth/weight/total drops/no-buffer drops/interleaves) 6/32384/0/0/0    
   Conversation 15, linktype: ip, length: 482 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

Usted puede ver en los debugs que los primeros cuatro paquetes de 482 bytes son seguidos por los paquetes 82-byte. Estos paquetes pequeños salen del router antes que los paquetes más grandes. Esto indica que, en cuanto ocurre la congestión, los paquetes pequeños tienen prioridad sobre los más grandes.

Utilice las fórmulas de la ponderación y del horario de programación dadas en el cálculo de la sección de la ponderación para verificar esto.

Etapa 2

Si usted aumenta el límite del anillo de transmisión a cinco y los paquetes grandes entonces son 482 bytes, del acuerdo a la salida anterior, usted deben ver seis paquetes de 482 bytes antes de que ocurra la congestión, seguidos por cuatro paquetes de 82 bytes, entonces otros cuatro paquetes de 482 bytes:

   .Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:57.841: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:57.845: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:58.797: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:58.801: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.840: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:00.844: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:01.796: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:01.800: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol  

Como usted puede ver aquí, esto es de hecho qué sucede.

Etapa 3

El tamaño de partícula es 512 bytes. Por lo tanto, si el anillo de transmisión se expresa en las partículas, y usted utilice los paquetes levemente más grandes que el tamaño de partícula, cada uno toma dos partículas. Esto es ilustrada por el uso de los paquetes de 582 bytes y de un anillo de transmisión de tres. Con estos parámetros, usted debe ver tres paquetes de 582 bytes. Uno se envía sin el tráfico en la interfaz ATM, esa las hojas tres partículas libremente. Por lo tanto, dos o más paquetes pueden ser almacenados en cola, seguidos por cuatro paquetes de 82 bytes y luego siete paquetes de 582 bytes:

   .Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:35.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:37.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:37.388: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:39.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:39.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol  

Etapa 4

Tome un tamaño de paquetes de 1482 (tres partículas) y defina un anillo de transmisión de cinco. Si el anillo de transmisión se define en las partículas, usted ve algo similar:

  • Un paquete transmitido inmediatamente

  • Un paquete que toma tres de las cinco partículas

  • Un paquete hecho cola porque dos partículas están libres

   .Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:47.371: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:47.375: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:48.763: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:48.767: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:54.415: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:54.419: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 

Resumen

De las pruebas realizadas, usted puede concluir éstos:

  • En los PVC lentos sin el WFQ, el tráfico a granel afecta el pequeño tráfico, tal como ping que son atascados hasta que se habilite el WFQ.

  • El tamaño del anillo de transmisión (tx-timbre-límite) determina cómo rápidamente el comienzo del Mecanismo para formar la cola hacer su trabajo. Usted puede ver el impacto de esto con el aumento del ping RTT cuando el límite del anillo de transmisión aumenta. Por lo tanto, si se necesita implementar WFQ o LLQ, tiene sentido reducir el límite de anillo de transmisión.

  • El WFQ que utiliza el CBWFQ da prioridad de hecho a los pequeños tráficos sobre el tráfico a granel.


Información Relacionada


Document ID: 10049