Modo de transferencia asíncrona (ATM) : Administración de tráfico ATM

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

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


Contenido


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.

prerrequisitos

Requisitos

Los Quien lea este documento deben ser familiares con estos conceptos:

  • mecanismo de almacenamiento en cola de prioridad del legado de Cisco de los permisos del prioridad-grupo o del prioridad-grupo del Frame Relay. Soportes hasta cuatro niveles de colas de administración del tráfico de prioridad.

  • prioridad de IP RTP o Prioridad de IP RTP en Frame Relay - Las coincidencias en los números del puerto UDP para el tráfico del Real-Time Protocol (RTP) que encapsula los paquetes de VoIP y colocan estos paquetes en un priority queue.

  • prioridad - La característica del low latency queueing de Cisco de los permisos (LLQ) y utiliza la estructura de comando del QoS Command-Line Interface de la calidad de servicio modular (CLI).

Un router puede señalar las caídas de resultados cuando se configuran ninguno de estos métodos, pero hay diferencias funcionales importantes entre los métodos y la razón de los descensos 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. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si usted está trabajando en una red en funcionamiento, asegúrese de que usted entienda el impacto potencial del comando any antes de que usted lo utilice.

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. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

Para más información sobre las convenciones sobre documentos, refiera a los convenios usados en los consejos técnicos de Cisco.

Rechazo con prioridad IP RTP y LLQ

La guía de configuración del Cisco IOS advierte contra las caídas de resultados con estos mecanismos de almacenamiento en cola de prioridad:

  • ip rtp priority Porque el comando ip rtp priority da la prioridad absoluta sobre el otro tráfico, debe ser utilizado con el 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 usted especifica el comando priority para una clase, toma un argumento de ancho de banda que dé el ancho de banda máximo. En caso de congestión, la vigilancia se utiliza para caer los 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 había siempre tráfico en la cola de alta prioridad, las colas de menor prioridad eran hambrientas del ancho de banda y de los paquetes que iban a las 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.

/image/gif/paws/10105/pqpic.gif

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 el PQ la interfaz de Ethernet ahora está utilizando cuatro colas de administración del tráfico de prioridad con los límites de cola diversos, tal y como se muestra en de la salida abajo:

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

Utilizan al comando priority-list {list-number} de asignar los 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. La cola de alta prioridad se analiza primero, entonces la cola de Prioridad media, y así sucesivamente. El paquete en el jefe de la cola más prioritaria se elige 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 de llegada haría la profundidad de espera en cola actual exceder el límite de cola configurado, se cae el paquete. 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.

/image/gif/paws/10105/policing.gif

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 el permiso para que la fuente envíe algunos bits en 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 próximo paquete es 800 bytes, el paquete se excede, y se cae. No se toman bytes de la cubeta con ficha.

Pasos de solución de problemas para diagnosticar fallas

Paso 1 – Recopilar datos

Los pasos para recoger los datos se muestran abajo.

  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 fondo de sus patrones de tráfico y niveles de tráficog. 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. Los descensos de la salida de la interfaz de la demostración contrarios deben visualizar el agregado total de todos los descensos en la salida, incluyendo el descarte WRED, el descarte debido a la escasez de búfer (errores del “no hay búfer suficiente”), e incluso los descartes en la memoria de adaptador de puerto a bordo.

      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" en forma separada.

      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: La salida de siguiente ejemplo visualiza los valores concordantes para los contadores de los “paquetes” y del “pkts matched”. 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 promedio de los paquetes?

    • ¿En qué dirección fluyen las tramas de tamaño MTU? Muchos flujos de tráfico son asíncronos en cuanto 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? El TCP permite que cada flujo envíe un número autorizado de paquetes antes de que la fuente necesite suspender la transmisión y esperar el destino para reconocer 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:

    /image/gif/paws/10105/priorityqueuedrops1.jpg

  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 el monitorear.

Paso 2 – Asegure el suficiente ancho de banda

Con el LLQ, la vigilancia permite el tratamiento justo de otros paquetes de datos en el otro Class-Based Weighted Fair Queuing (CBWFQ) o las colas de administración del tráfico WFQ. 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 de IP RTP no permitirá el tráfico más allá de la cantidad afectada un aparato.

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 usted afectó un aparato 24 anchos de banda del kbps, la cantidad estándar requerida para la transmisión de voz, al priority queue. Esta asignación parece segura porque la transmisión de los paquetes de voz ocurre a una velocidad de bit constante. Sin embargo, porque la red y el router o el Switch pueden utilizar algo del ancho de banda para producir el jitter y el retardo, afectar un aparato levemente más que la cantidad necesaria de ancho de banda (tal como 25 kbps) asegura la constancia y la Disponibilidad.

El ancho de banda afectado un aparato para un priority queue incluye siempre el encabezado de encapsulado de la capa 2. No incluye la Verificación de redundancia cíclica (CRC). ¿(Refiérase a qué bytes son contados haciendo cola del IP to ATM CoS? para más información.) Aunque sea solamente algunos bytes, los CRC impones un impacto cada vez mayor como flujos de tráfico incluyen un número más elevado de los pequeños paquetes.

Además, en las interfaces ATM, el ancho de banda afectado un aparato para un priority queue no incluye los gastos indirectos siguientes del impuesto de célula 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.

  • 4-byte CRC del remolque del capa 5 de adaptación del ATM (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. Usted debe también permitir el ancho de banda para la posibilidad del jitter introducida por los dispositivos de red en el trayecto de la voz. Refiera a la descripción general de características del low latency queueing.

Al usar la prioridad que hace cola para llevar los paquetes de VoIP, refiera a la voz sobre IP - por el consumo de ancho de banda de la 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 es dirigido al priority queue porque el LLQ utiliza un policer, no un shaper. 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 es el número de tokens mayor o igual tamaño de paquetes, se envía el paquete, y el token bucket decremented. 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.

La salida de muestra siguiente fue generada en una atmósfera PVC con una velocidad continua de celda del kbps 128. 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 la clase de prioridad puede utilizar y puede dar el aspecto que las clases de prioridad están consiguiendo a más que su reparto justo 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 consecuencia, algunos paquetes Tail-fueron caídos. El Id. de bug Cisco CSCdr51979 (clientes registrados solamente) resuelve este problema permitiendo que el tamaño del priority queue crezca tan profundo como permitido por el medidor del tráfico.

El producto siguiente fue capturado 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 tarifas del descenso no representan las tarifas de transmisión real y no están incluyendo los paquetes que se sientan en el shaper 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 Precaución:  Antes de que utilice los comandos debug, consulte Información Importante sobre los Comandos Debug. El comando debug priority puede imprimir una gran cantidad de salida de los debugs perturbadora en un router de producción. La cantidad depende del nivel de congestión.

La salida de muestra siguiente fue generada 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 la siguiente salida de prioridad de debug, 64 indica la profundidad real del priority queue cuando el paquete fue caído.

*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 (clientes registrados solamente). Resuelva este problema clasificando la cola de entrada y la cola de salida apropiadamente para prevenir el Input Drops y para permitir que el Mecanismo para formar la cola de la prioridad de salida tome el efecto.

  • Habilitar una característica que no se soporte en el CEF-Switched o el trayecto Fast-Switched hace un gran número de paquetes ser process-switched. 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 en el Id. de bug Cisco CSCdv86818 (clientes registrados solamente).

Descartes de las colas de prioridad y Frame Relay

El Frame Relay es un caso especial en cuanto a limpiar el priority queue. 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: “El PQ se limpia para asegurarse de que las colas justas no son hambrientas del ancho de banda. Cuando configura PQ, especifica en kbps la cantidad máxima de ancho de banda disponible para esa cola. Se caen los paquetes que exceden 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. El IOS 12.2 quita esta excepción. El PQ todavía se limpia con el FRF.12, pero otros paquetes sin conformidad a normas se caen solamente si hay congestión.


Información Relacionada


Document ID: 10105