Resolución de problemas de paquetes descartados en colas de salida con organización de cola según la prioridad

Introducción

Este documento proporciona consejos sobre cómo resolver problemas de caídas de salida producidas por una configuración del mecanismo de almacenamiento en cola de prioridad en una interfaz del router.

Prerequisites

Requirements

Los lectores de este documento deben estar familiarizados con estos conceptos:

• priority-group o frame-relay priority-group- Habilita el mecanismo de colocación en cola de prioridad heredada de Cisco. Admite hasta cuatro niveles de colas de prioridad.

• ip rtp priority o frame-relay ip rtp priority: coincide con los números de puerto UDP para el tráfico de protocolo en tiempo real (RTP) que encapsula los paquetes VoIP y coloca estos paquetes en una cola prioritaria.

• priority: habilita la función de cola de baja latencia (LLQ) de Cisco y utiliza la estructura de comandos de la interfaz de línea de comandos (CLI) de QoS de calidad de servicio modular.

Un router puede informar de caídas de salida cuando se configura cualquiera de estos métodos, pero hay importantes diferencias funcionales entre los métodos y la razón de las caídas en cada caso.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si trabaja en una red en vivo, asegúrese de entender el posible impacto de cualquier comando antes de ejecutarlo.

Componentes Utilizados

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

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

Para obtener más información sobre las convenciones del documento, refiérase a Convenciones Utilizadas en Consejos Técnicos de Cisco.

Fallas con ip rtp priority y LLQ

La Guía de Configuración de Cisco IOS advierte contra caídas de salida con estos mecanismos de colocación en cola de prioridad:

• ip rtp priority Debido a que el comando ip rtp priority da prioridad absoluta sobre otro tráfico, se debe utilizar con cuidado. En caso de congestión, si el tráfico excede el ancho de banda configurado, entonces todo el excedente de tráfico es eliminado.

• comando priority y LLQ: Cuando se especifica el comando priority para una clase, se necesita un argumento bandwidth que proporciona el ancho de banda máximo. En caso de congestión, la regulación se utiliza para descartar paquetes cuando se excede el ancho de banda.

Estos dos mecanismos utilizan un regulador integrado para medir el flujo de tráfico. El objetivo del regulador es garantizar que el planificador de envío a cola atienda las otras colas. En la característica de formación de cola prioritaria original de cisco, que utiliza los comandos priority-group y priority-list, el planificador siempre atendía a la cola de mayor prioridad en primer lugar. Si siempre había tráfico en la cola de alta prioridad, las colas de menor prioridad se veían privadas de ancho de banda y los paquetes iban a colas sin prioridad.

Caídas con almacenamiento en cola de prioridad antigua

La cola de prioridad (PQ) es el mecanismo para formar la cola de prioridad antigua de cisco. Tal como se ejemplifica a continuación, PQ admite hasta cuatro niveles de colas: alto, medio, normal y bajo.

Si se activa la prioridad de cola, la interfaz cambia el visor de cola de salida según se muestra a continuación. Antes de la cola prioritaria, la interfaz de Ethernet utiliza una sola cola de retención de salida con el tamaño de cola predeterminado de 40 paquetes.

R6-2500# show interface ethernet0 
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1) 
  Internet address is 42.42.42.2/24 
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 
  Encapsulation ARPA, loopback not set, keepalive set (10 sec) 
  ARP type: ARPA, ARP Timeout 04:00:00 
  Last input 00:00:03, output 00:00:02, output hang never 
  Last clearing of "show interface" counters never 
  Queueing strategy: fifo 
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     239407 packets input, 22644297 bytes, 0 no buffer 
     Received 239252 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     0 input packets with dribble condition detected 
     374436 packets output, 31095372 bytes, 0 underruns 
     0 output errors, 1 collisions, 13 interface resets 
     0 babbles, 0 late collision, 8 deferred 
     0 lost carrier, 0 no carrier 
     0 output buffer failures, 0 output buffers swapped out

Después de habilitar PQ, la interfaz Ethernet ahora está usando cuatro colas de prioridad con límites de cola variables, como se muestra en el siguiente resultado:

R6-2500(config)# interface ethernet0 
R6-2500(config-if)# priority-group 1 
R6-2500(config-if)# end 
R6-2500# show interface ethernet 0 
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1)
  Internet address is 42.42.42.2/24 
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 
  Encapsulation ARPA, loopback not set, keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00 
  Last input 00:00:03, output 00:00:03, output hang never 
  Last clearing of "show interface" counters never 
  Input queue: 0/75/0 (size/max/drops); Total output drops: 0
  Queueing strategy: priority-list 1 
  Output queue (queue priority: size/max/drops): 
     high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     239411 packets input, 22644817 bytes, 0 no buffer
     Received 239256 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     0 input packets with dribble condition detected 
     374440 packets output, 31095658 bytes, 0 underruns
     0 output errors, 1 collisions, 14 interface resets
     0 babbles, 0 late collision, 8 deferred 
     0 lost carrier, 0 no carrier 
     0 output buffer failures, 0 output buffers swapped out

El comando priority-list {list-number} se utiliza para asignar flujos de tráfico a una cola específica. A medida que los paquetes llegan a una interfaz, las colas de prioridad de la interfaz son escaneadas en función de los paquetes en un orden de prioridad descendente. Primero se analiza la cola de alta prioridad, luego la cola de prioridad media, etc. Se elige el paquete en la cabecera de la cola de prioridad más alta para la transmisión. Este procedimiento se repite cada vez que se está por enviar un paquete.

Cada cola está definida por una longitud máxima o por la catidad máxima de paquetes que la cola puede retener. Cuando un paquete que llega hace que la profundidad de la cola actual exceda el límite de cola configurado, el paquete se descarta. Por lo tanto, como se indicó anteriormente, las caídas de salida con PQ por lo general se deben al exceso del límite de cola y no a un regulador interno, como en el caso de LLQ. El comando priority-list list-number queue-limit cambia el tamaño de una cola de prioridad.

Medición del tráfico con cubeta con ficha

LLQ y la prioridad IP RTP ponen en funcionamiento el vigilante incorporado usando una cubeta con ficha como un sistema de medida de tráfico. Esta sección describe el concepto de token bucket.

Una cubeta con ficha no posee una política de prioridad o descarte. La metáfora de cubeta con fichas trabaja a lo largo de las siguientes líneas:

• Los token ingresan al bloque de memoria a una velocidad determinada.

• Cada token significa permiso para que el origen envíe un determinado número de bits a la red.

• Para enviar un paquete, el regulador del tráfico debe ser capaz de retirar de la cubeta una cantidad de tokens equivalente al tamaño del paquete.

• Si no hay suficientes fichas en la cubeta como para enviar un paquete, el paquete espera hasta que la cubeta tenga suficientes fichas (en el caso de un modelador) o el paquete se descarta o se rebaja (en el caso de un vigilante).

• La cubeta posee una capacidad especificada. Si la capacidad del compartimiento de memoria se encuentra completa, todos los símbolos nuevos que lleguen serán descartados y no estarán disponibles para paquetes futuros. De esta manera, en cualquier momento, la ráfaga más grande que una aplicación puede enviar a la red es más o menos proporcional al tamaño de la cubeta. El token bucket permite la saturación, pero la limita.

Observemos un ejemplo con paquetes y una velocidad de información suscrita (CIR) de 8000 bps.

• En este ejemplo, las cubetas con fichas iniciales se inician en forma completa a 1000 bytes.

• Cuando llega un paquete de 450 bytes, éste se ajusta porque hay suficientes bytes en la cubeta de ficha de conformidad. Se envía el paquete y se eliminan 450 bytes de la cubeta con fichas, lo que deja 550 bytes.

• Cuando el próximo paquete llega 0,25 segundos más tarde, se agregan 250 bytes a la cubeta con fichas ((0,25 * 8000)/8), dejando 700 bytes en la cubeta con fichas. Si el siguiente paquete es de 800 bytes, el paquete excede y se descarta. No se toman bytes de la cubeta con ficha.

Pasos de solución de problemas para diagnosticar fallas

Paso 1 – Recopilar datos

A continuación se muestran los pasos para recopilar datos.

1. Ejecute los siguientes comandos repetidas veces y determine la velocidad y la frecuencia con la que se incrementan las desconexiones. Utilice la salida para establecer una línea de base de sus patrones de tráfico y niveles de tráfico. Determine cuál es el índice de pérdida "normal" en la interfaz.

   • show queueing interface

     router# show queueing interface hssi 0/0/0
               Interface Hssi0/0/0 queueing strategy: priority
     
               Output queue utilization (queue/count)
     
                high/12301 medium/4 normal/98 low/27415

   • show interface - Supervise el valor de carga que aparece en la salida. Además, asegúrese de que la suma de los conteos de caídas por cola en el resultado de show interface sea equivalente al conteo de caídas del resultado. El contador de caídas de salida show interface debe mostrar el total de todas las caídas en la salida, incluyendo descarte WRED, descarte debido a la escasez de búfer ("sin errores de búfer") e incluso descarte en la memoria del adaptador de puerto integrada.

     router# show interface serial 4/1/2
     
     Serial4/1/2 is up, line protocol is up 
     Hardware is cyBus Serial 
     Description: E1 Link to 60W S9/1/2 Backup 
     Internet address is 169.127.18.228/27 
     MTU 1500 bytes, BW 128 Kbit, DLY 21250 usec, rely 255/255, load 183/255 
     Encapsulation HDLC, loopback not set, keepalive set (10 sec) 
     Last input 00:00:00, output 00:00:00, output hang never 
     Last clearing of "show interface" counters 5d10h 
     Input queue: 0/75/0 (size/max/drops); Total output drops: 68277 
     Queueing strategy: priority-list 7 
     Output queue: high 0/450/0, medium 0/350/143, normal 0/110/27266, low 0/100/40868 
     5 minute input rate 959000 bits/sec, 419 packets/sec 
     5 minute output rate 411000 bits/sec, 150 packets/sec 
     144067307 packets input, 4261520425 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
     42 input errors, 34 CRC, 0 frame, 0 overrun, 1 ignored, 8 abort 
     69726448 packets output, 2042537282 bytes, 0 underruns 
     0 output errors, 0 collisions, 0 interface resets 
     0 output buffer failures, 46686454 output buffers swapped out 
     0 carrier transitions

     Nota: Algunas interfaces muestran valores "txload" y "rxload" separados.

     Hssi0/0/0 is up, line protocol is up 
      Hardware is cyBus HSSI 
      MTU 1500 bytes, BW 7500 Kbit, DLY 200 usec, 
      reliability 255/255, txload 138/255, rxload 17/255 
      Encapsulation FRAME-RELAY IETF, crc 16, loopback not set 
      Keepalive set (5 sec) 
      LMI enq sent 4704, LMI stat recvd 4704, LMI upd recvd 0, DTE LMI up 
      LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 
      LMI DLCI 1023 LMI type is CISCO frame relay DTE 
      Broadcast queue 0/256, broadcasts sent/dropped 8827/0, interface 
      broadcasts 7651 
      Last input 00:00:00, output 00:00:00, output hang never 
      Last clearing of "show interface" counters 06:31:58 
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 84 
      Queueing strategy: priority-list 1 
      Output queue (queue priority: size/max/drops): 
      high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/84 
      5 minute input rate 524000 bits/sec, 589 packets/sec 
      5 minute output rate 4080000 bits/sec, 778 packets/sec 
      11108487 packets input, 1216363830 bytes, 0 no buffer 
      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
      0 parity 
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
      15862186 packets output, 3233772283 bytes, 0 underruns 
      0 output errors, 0 applique, 1 interface resets 
      0 output buffer failures, 2590 output buffers swapped out 
      0 carrier transitions 
      LC=down CA=up TM=down LB=down TA=up LA=down

   • show policy-map interface nombre de la interfaz - Busca un valor distinto de cero para el contador de "descarte de paquetes".

     Router# show policy-map interface s1/0
      Serial1/0.1: DLCI 100 -
      output : mypolicy
       Class voice
        Weighted Fair Queueing
            Strict Priority
            Output Queue: Conversation 72 
              Bandwidth 16 (kbps) Packets Matched 0
             (pkts discards/bytes discards) 0/0
       Class immediate-data
        Weighted Fair Queueing
            Output Queue: Conversation 73 
              Bandwidth 60 (%) Packets Matched 0
              (pkts discards/bytes discards/tail drops) 0/0/0
              mean queue depth: 0
              drops: class  random   tail     min-th   max-th   mark-prob 
                     0      0        0        64       128      1/10
                     1      0        0        71       128      1/10
                     2      0        0        78       128      1/10
                     3      0        0        85       128      1/10
                     4      0        0        92       128      1/10
                     5      0        0        99       128      1/10
                     6      0        0        106      128      1/10
                     7      0        0        113      128      1/10
                     rsvp   0        0        120      128      1/10

     Nota: El siguiente ejemplo de resultado muestra valores coincidentes para los contadores "paquetes" y "paquetes coincidentes". Esta condición indica que una gran cantidad de paquetes se está conmutando por proceso o que la interfaz está experimentando una congestión extrema. Estas dos condiciones pueden conducir al exceso del límite de una clase de cola y deberían investigarse.

     router# show policy-map interface
     
     Serial4/0 
     
     Service-policy output: policy1 
     
     Class-map: class1 (match-all) 
     189439 packets, 67719268 bytes 
     5 minute offered rate 141000 bps, drop rate 0 bps 
     Match: access-group name ds-class-af3 
     Weighted Fair Queueing 
     Output Queue: Conversation 265 
     Bandwidth 50 (%) Max Threshold 64 (packets) 
     (pkts matched/bytes matched) 189439/67719268 
     (depth/total drops/no-buffer drops) 0/0/0

2. Caracterice los flujos del tráfico y los paquetes en esos tráficos.

   • ¿Cuál es el tamaño medio del paquete?

   • ¿En qué dirección fluyen las tramas de tamaño MTU? Muchos flujos de tráfico son asincrónicos con respecto a la carga. Por ejemplo, con una descarga de un FTP, la mayoría de los paquetes del tamaño de MTU fluyen del servidor del FTP al cliente. Los paquetes desde el cliente FTP al servidor son simples TCP ACK.

   • ¿Los paquetes utilizan TCP o UDP? TCP permite que cada flujo envíe un número autorizado de paquetes antes de que el origen necesite suspender la transmisión y esperar a que el destino reconozca los paquetes transmitidos.

3. Con Frame Relay, determine si las caídas se producen en la cola de la interfaz o en la cola por VC. El siguiente diagrama ilustra el flujo de paquetes a través del circuito virtual de Frame Relay:

   

4. La organización de cola según la prioridad admite hasta cuatro colas de salida, una por cada nivel de cola de prioridad y se define cada cola como un límite de cola. Antes de colocar el paquete en una cola, el sistema de colocación en cola verifica el tamaño de ésta en función del límite de cola configurado. Si la cola seleccionada está completa, el router dejará de transmitir el paquete. Intente aumentar el tamaño de la cola con el comando priority-list {#} queue-limit y reanude la supervisión.

Paso 2 – Asegure el suficiente ancho de banda

Con LLQ, la regulación permite un tratamiento justo de otros paquetes de datos en otras colas de cola equilibrada ponderada (CBWFQ) o WFQ basadas en clases. Para evitar pérdidas de paquetes, asegúrese de asignar una cantidad óptima de ancho de banda en la cola de prioridad, tomando en cuenta el tipo de códec utilizado y las características de la interfaz. La prioridad IP RTP no permitirá el tráfico más allá de la cantidad asignada.

Siempre es más seguro asignar a la cola de prioridad un poco más de la cantidad normal de ancho de banda requerida. Por ejemplo, suponga que asignó un ancho de banda de 24 kbps, la cantidad estándar requerida para la transmisión de voz, a la cola de prioridad. Esta asignación parece segura porque la transmisión de los paquetes de voz ocurre a una velocidad de bit constante. Sin embargo, debido a que la red y el router o switch pueden utilizar parte del ancho de banda para producir fluctuación y retardo, asignar un poco más de la cantidad de ancho de banda requerida (como 25 kbps) asegura la constancia y disponibilidad.

El ancho de banda asignado para una cola de prioridad siempre incluye el encabezado de encapsulación de Capa 2. No incluye la Verificación de redundancia cíclica (CRC). (Consulte ¿Qué Bytes son contados por IP a la Colocación en Cola ATM CoS? para obtener más información.) Aunque es sólo de unos cuantos bytes, el CRC impone un impacto creciente pues los flujos de tráfico incluyen un mayor número de paquetes pequeños.

Además, en las interfaces ATM, el ancho de banda asignado para una cola de prioridad no incluye la siguiente sobrecarga de impuesto de celda ATM:

• Cualquier relleno por parte de la Segmentación y reensamblado (SAR) para hacer de la última celda de un paquete un múltiplo par de 48 bytes.

• CRC de 4 bytes de la cola ATM Adaptation Layer 5 (AAL5).

• Encabezado de celdas ATM de 5 bytes.

Cuando calcula la cantidad de ancho de banda a asignar para una clase de prioridad determinada, debe considerar el hecho de que los encabezados de Capa 2 están incluidos. Cuando se utiliza ATM, debe justificar el hecho de que la sobrecarga del impuesto de célula ATM no está incluida. También debe permitir el ancho de banda para la posibilidad de fluctuación introducida por los dispositivos de red en la ruta de voz. Refiérase a Descripción General de la Función Low Latency Queueing.

Cuando utilice la colocación en cola de prioridad para transportar paquetes VoIP, consulte Voz sobre IP - Consumo de ancho de banda por llamada.

Paso 3 – Asegure el tamaño de ráfaga suficiente

El tratamiento de la serie de paquetes que abandona una interfaz por medio de la cola de prioridad depende del tamaño del paquete y del número de bytes que permanecen en la cubeta con ficha. Es importante considerar las características del flujo de tráfico que se dirige a la cola de prioridad porque LLQ utiliza un regulador, no un modelador. Un vigilante utiliza la cubeta con ficha de la siguiente manera:

• El contador dinámico se llena de fichas sobre la base de velocidad de clase para un máximo del parámetro de ráfaga.

• Si el número de tokens es mayor o igual al tamaño del paquete, se envía el paquete y se reduce la cubeta con ficha. De no ser así, el paquete se pierde.

El valor de ráfaga predeterminado del medidor de tráfico de la cubeta con ficha de LLQ se computa como 200 milisegundos de tráfico en el índice de ancho de banda configurado. En algunos casos, el valor predeterminado es inapropiado, especialmente cuando el tráfico TCP entra en la cola de prioridad. Generalmente, los flujos TCP son intermitentes y pueden necesitar un tamaño de ráfaga mayor que el asignado de manera predeterminada por el sistema de colocación en cola, particularmente en links lentos.

El siguiente ejemplo de salida se generó en un PVC ATM con una velocidad de celda sostenida de 128 kbps. El sistema de colas ajusta el tamaño de ráfaga a medida que cambia el valor especificado con el comando priority.

7200-17# show policy-map int atm 4/0.500
 ATM4/0.500: VC 1/500 - 
  
Service-policy output: drops 

    Class-map: police (match-all)
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 
      Weighted Fair Queueing 
        Strict Priority 
        Output Queue: Conversation 24 
        Bandwidth 90 (%) 
        Bandwidth 115 (kbps) Burst 2875 (Bytes) 
        
!--- Burst value of 2875 bytes is assigned when !--- the reserved bandwidth value is 115 kbps. 

        (pkts matched/bytes matched) 0/0 
        (total drops/bytes drops) 0/0 

    Class-map: class-default (match-any) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 

7200-17# show policy-map int atm 4/0.500 
 ATM4/0.500: VC 1/500 - 

  Service-policy output: drops 

    Class-map: police (match-all) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 
      Weighted Fair Queueing 
        Strict Priority 
        Output Queue: Conversation 24 
        Bandwidth 50 (%) 
        Bandwidth 64 (kbps) Burst 1600 (Bytes) 
        
!--- Burst value changes to 1600 bytes when the !--- reserved bandwidth value is changed to 64 kbps. 

        (pkts matched/bytes matched) 0/0 
        (total drops/bytes drops) 0/0 

    Class-map: class-default (match-any) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any

La funcionalidad de LLQ se amplió para permitir un tamaño configurable de Ráfaga comprometida (Bc) con la función de Configuración de tamaño de ráfaga en almacenamiento en cola de baja latencia. Con esta nueva funcionalidad, la red puede admitir ráfagas de tráfico temporales y manejar el tráfico de la red de manera más eficiente.

Use el parámetro burst con el comando priority para aumentar el valor de la ráfaga de 1600 bytes a 3200 bytes.

policy-map AV 
  class AV 
  priority percent 50 3200

Nota: Un valor alto aumenta el ancho de banda efectivo que puede utilizar la clase de prioridad y puede dar la apariencia de que las clases de prioridad están obteniendo más de su porción justa del ancho de banda.

Además, el sistema de envío a cola asignó originalmente un límite de cola interna de 64 paquetes a la cola de latencia baja. En algunos casos, cuando una ráfaga de 64 paquetes llega a la cola prioritaria, el medidor del tráfico determina que la ráfaga corresponde a la velocidad configurada, pero la cantidad de paquetes excede el límite de la cola. Como resultado, algunos paquetes fueron descartados. El Id. de error de Cisco CSCdr51979 (sólo clientes registrados) resuelve este problema permitiendo que el tamaño de cola de prioridad crezca tan profundo como lo permite el medidor de tráfico.

El siguiente resultado se capturó en un PVC de Frame Relay configurado con un CIR de 56 kbps. En el primer conjunto de ejemplo de resultado, la velocidad combinada ofrecida en las clases c1 y c2 es de 76 kbps. La razón es que los valores calculados de las velocidades ofrecidas menos las velocidades de descarte no representan las velocidades de transmisión reales y no incluyen los paquetes sentados en el modelador antes de que se transmitan.

router# show policy-map int s2/0.1
  Serial2/0.1: DLCI 1000 - 

   Service-policy output: p 

     Class-map: c1 (match-all) 
       7311 packets, 657990 bytes 
       30 second offered rate 68000 bps, drop rate 16000 bps 
       Match: ip precedence 1 
       Weighted Fair Queueing 
         Strict Priority 
         Output Queue: Conversation 24 
         Bandwidth 90 (%) 
         Bandwidth 50 (kbps) Burst 1250 (Bytes) 
         (pkts matched/bytes matched) 7311/657990 
         (total drops/bytes drops) 2221/199890 

     Class-map: c2 (match-all) 
       7311 packets, 657990 bytes 
       30 second offered rate 68000 bps, drop rate 44000 bps 
       Match: ip precedence 2 
       Weighted Fair Queueing 
         Output Queue: Conversation 25 
         Bandwidth 10 (%) 
         Bandwidth 5 (kbps) Max Threshold 64 (packets) 
         (pkts matched/bytes matched) 7310/657900 
         (depth/total drops/no-buffer drops) 64/6650/0 

     Class-map: class-default (match-any) 
       2 packets, 382 bytes 
       30 second offered rate 0 bps, drop rate 0 bps 
       Match: any

En este segundo conjunto de resultados, se normalizaron los contadores de show policy-map interface. En el PVC de 56 kbps, la clase c1 está enviando alrededor de 50 kbps y la clase c2 alrededor de 6 kbps.

router# show policy-map int s2/0.1 
  Serial2/0.1: DLCI 1000 - 

   Service-policy output: p 

     Class-map: c1 (match-all) 
       15961 packets, 1436490 bytes 
       30 second offered rate 72000 bps, drop rate 21000 bps 
       Match: ip precedence 1 
       Weighted Fair Queueing 
         Strict Priority 
         Output Queue: Conversation 24 
         Bandwidth 90 (%) 
         Bandwidth 50 (kbps) Burst 1250 (Bytes) 
         (pkts matched/bytes matched) 15961/1436490 
         (total drops/bytes drops) 4864/437760 

     Class-map: c2 (match-all) 
       15961 packets, 1436490 bytes 
       30 second offered rate 72000 bps, drop rate 66000 bps 
       Match: ip precedence 2 
       Weighted Fair Queueing 
         Output Queue: Conversation 25 
         Bandwidth 10 (%) 
         Bandwidth 5 (kbps) Max Threshold 64 (packets) 
         (pkts matched/bytes matched) 15960/1436400 
         (depth/total drops/no-buffer drops) 64/14591/0 

     Class-map: class-default (match-any) 
       5 packets, 1096 bytes 
       30 second offered rate 0 bps, drop rate 0 bps 
       Match: any

Paso 4 – Prioridad de depuración

El comando debug priority muestra el resultado del almacenamiento de prioridades en cola si los paquetes se eliminan de la cola de prioridades.

Precaución: Antes de utilizar los comandos debug, consulte Información Importante sobre los Comandos Debug. El comando debug priority puede imprimir una gran cantidad de resultados de depuración disruptiva en un router de producción. La cantidad depende del nivel de congestión.

El siguiente ejemplo de resultado se generó en un Cisco 3640.

r3-3640-5# debug priority 
Priority output queueing debugging is on 

r3-3640-5# ping 10.10.10.2 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms 
r3-3640-5# 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:41: PQ: Serial0/1 output (Pk size/Q 13/0) 
r3-3640-5#no debug priority 
00:42:51: PQ: Serial0/1 output (Pk size/Q 13/0) 
Priority output queueing debugging is off

En el siguiente resultado de prioridad de depuración, 64 indica la profundidad de cola de prioridad real en el momento en que se descartó el paquete.

*Feb 28 16:46:05.659:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.671:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.679:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.691:WFQ:dropping a packet from the priority queue 64

Otras causas de caídas

Las siguientes razones para las caídas de salida con LLQ las detectó el Centro de la asistencia técnica de Cisco (TAC) durante la resolución de problemas de los casos y se las documentó en un informe de fallas de funcionamiento Cisco:

• El aumento de valores de umbral máximos de detección temprana aleatoria ponderada (WRED) en otra clase agotó las memorias intermedias disponibles y provocó fallas en la cola de prioridad. Para ayudar a diagnosticar este problema, está planeada la incorporación de un contador de "caídas sin búfer" para la clase de prioridad para una futura versión del IOS.

• Si el límite de cola de la interfaz de entrada es menor que el límite de cola de la interfaz de salida, las caídas de paquetes pasan a la interfaz de entrada. Estos síntomas se documentan en el Id. de bug Cisco CSCdu89226 (sólo clientes registrados) . Resuelva este problema dimensionando la cola de entrada y la cola de salida apropiadamente para evitar caídas de entrada y permitir que el mecanismo de cola de prioridad de salida entre en vigor.

• La habilitación de una función que no se soporta en el trayecto conmutado por CEF o fast-switched hace que un gran número de paquetes sean conmutados por proceso. Con LLQ, se regulan los paquetes conmutados por proceso, independientemente de si la interfaz está congestionada o no. En otras palabras, incluso si la interfaz no está congestionada, el sistema de colocación en cola mide los paquetes que son conmutados por proceso y se asegura de que la carga ofrecida no supere el valor de ancho de banda configurado con el comando priority. Este problema se documenta con el ID de bug de Cisco CSCdv86818 (sólo clientes registrados) .

Caídas de la cola prioritaria y retransmisión de tramas

Frame Relay es un caso especial con respecto a la regulación de la cola de prioridad. La descripción general de la cola de tiempo de latencia bajo para la característica de retransmisión de tramas indica la siguiente advertencia: "La PQ es controlada para garantizar que las colas justas no se saturen de ancho de banda. Cuando configura PQ, especifica en kbps la cantidad máxima de ancho de banda disponible para esa cola. Se descartan los paquetes que excedan ese máximo". En otras palabras, originariamente, la cola de prioridades de una política de servicio configurada en una clase de mapa Frame Relay se controlaba durante periodos de congestión y no congestión. IOS 12.2 elimina esta excepción. La PQ todavía se controla con FRF.12, pero otros paquetes no conformes sólo se descartan si hay congestión.

Información Relacionada

• Página de Soporte de Qos (Calidad de Servicio)
• Módulo de la característica de regulación de tráfico de la versión 12.2 del software del IOS de Cisco
• Soporte Técnico - Cisco Systems