Introducción a VIP CPU operando a 99% y Rx-Side Buffering

Introducción

Este documento explica porqué el procesador de interfaz versátil (VIP) CPU se ejecuta en el 99%, y cuáles son buffers de la Cara de Rx.

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.

La información que contiene este documento se creó a partir de los dispositivos en 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 cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Antecedentes

Almacenamiento en búfer en lado de recepción está el proceso que ocurre cuando la interfaz de salida:

• se congestiona.

• utiliza el primer adentro, primero hacia fuera la Estrategia de almacenamiento en cola ((Primero en Entrar, Primero en Salir FIFO)).

El procesador de interfaz versátil entrante (VIP) no cae el paquete inmediatamente. En lugar, mitiga el paquete en su memoria del paquete hasta que los buffers estén disponibles para la interfaz saliente. De acuerdo con el tipo de VIP, memoria del paquete puede estar RAM estática (SRAM) o RAM dinámico síncrono SDRAM.

Conceptos básicos de arquitectura de las Cisco 7500 Series

Cada procesador de interfaz (IP o VIP de la herencia) tiene una conexión a un BUS DEL SISTEMA extendido de alta velocidad llamado un CyBus. La ruta/los Procesadores del switch (RSP) está conectada con dos CyBuses (véase el cuadro 1).

Cuadro 1 – Arquitectura de las Cisco 7500 Series

Teclea de los almacenes intermedios del paquete

Esta sección describe los diversos tipos de almacenes intermedios del paquete.

• Búferes del sistema en memoria del procesador en el RSP

  Estos buffers se utilizan para los paquetes process-switched. Usted puede ver estos buffers en la salida de las interfaces de la demostración (colas de entrada y de salida) y de los comandos show buffers. Un Cisco 7500 Series Router no debe hacer mucho Process-Switching. Por lo tanto, si usted tiene problemas con los búferes del sistema, significa que demasiados paquetes están enviados al nivel de proceso. Esto puede ser debido a muchos factores, por ejemplo:

  • Una tormenta de transmisiones

  • Inestabilidad en la red que causa las actualizaciones de ruteo

  • un ataque de "Negación de servicio" (DoS)

  • Una característica que no se soporta en el trayecto de Switching rápido (por ejemplo, X.25)

  • Paquetes del IP con las opciones.

  Para la información sobre cómo resolver problemas el process switching excesivo, refiera a estos documentos:

  • Resolución de problemas por uso excesivo de las CPU de los routers de Cisco

  • Resolución de problemas en los paquetes descartados en las colas de entrada y salida

• Memoria del paquete en los buffers RSP (MEMD)

  El tamaño de MEMD se repara en el 2 MB en el RSP7000, el RSP1, el RSP2, y el RSP4. En RSP8 y RSP16, el tamaño de MEMD es de 8 MB. El MEMD se distribuye entre todas las interfaces a la hora del bootup, cuando hay un Insertar/Remover en Línea (OIR), una recarga del microcódigo, un cambio de la Unidad máxima de transmisión (MTU) (MTU), o un complejo Cbus. Para más información sobre el complejo Cbus, refiérase a qué causa un "%RSP-3-RESTART: ¿Complejo cbus? Usted puede utilizar el comando show controllers cbus de marcar el estatus de los buffers MEMD.

  Cuando se afecta un aparato el MEMD, se crean estas estructuras:

  • Un local free queue (lfreeq) — Se asigna a cada interfaz, y se utiliza para los paquetes recibidos en esta interfaz.

  • Un global free queue (gfreeq) — También se afecta un aparato, y una interfaz puede recurrir a esa cola dentro de algunos límites.

  • Una cola de transmisión (txqueue o txq) — se asigna a cada interfaz, y se utiliza para los paquetes que salen a través de esta interfaz.

  • El transmit accumulator (txacc) — Representa el número de elementos en la cola de transmisión de la interfaz de salida (txqueue). Cuando el transmit accumulator (txacc) iguala el transmit limit (txlimit), se liberan todos los buffers. Cuando el txacc es 0, la cola es llena, y haciendo cola se permite.

• Memoria del paquete

  En un VIP, memoria del paquete contiene los almacenes intermedios del paquete (partículas) usados para los paquetes recibidos de o enviados a una interfaz VIP. El cuadro 2 representa el flujo de paquetes.

  Cuadro 2 – Flujo de paquetes

  

  Esta sección se centra en un VIP donde se habilita el Distributed Switching, porque almacenamiento en búfer en lado de recepción ocurre generalmente cuando un paquete sigue este tipo de trayecto de Switching. Diversos escenarios son posibles, que se explican aquí:

  Escenario 1: Cuando no hay congestión en la interfaz de salida.

  • Un paquete se recibe en un adaptador de puerto (PA) y se traslada a un almacén intermedio del paquete en memoria del paquete.

  • Si no puede el VIP distribuir-Switch el paquete, él adelante el paquete al RSP, que toma la decisión de Switching.

  • Si el VIP puede tomar la decisión de conmutación y la interfaz saliente se encuentra en el mismo VIP, el paquete es enviado hacia afuera por la interfaz saliente. El paquete reputa “localmente conmutado” en el VIP, porque no cruza el cbus.

  • Si el VIP puede tomar la decisión de conmutar y la interfaz saliente está en otra ranura, el VIP intenta copiar el paquete sobre el cbus en el txqueue (in MEMD) de la interfaz de salida.

  • El paquete después se copia (V) al IP saliente sobre el cbus y se envía en la línea.

  Escenario 2: Cuando se congestiona la interfaz de salida.

  Hay dos posibilidades:

  • Si se configura el almacenamiento en cola en la interfaz de salida, la VIP transfiere el paquete que se encuentra en la cola de transmisión en MEMD, y el paquete es retirado inmediatamente de la cola por el código de almacenamiento en cola.

    • Si se configura la espera RSP basada, el paquete se copia en los búferes del sistema en memoria del procesador en el RSP.

    • Si se utiliza la colocación en cola basada en VIP, el paquete se copia en la memoria del paquete del VIP saliente.

  • Si la Estrategia de almacenamiento en cola de la interfaz de salida es (Primero en Entrar, Primero en Salir FIFO), la interfaz no cae el paquete inmediatamente (esto es qué sucede normalmente con el (Primero en Entrar, Primero en Salir FIFO) cuando se congestiona una interfaz de salida). En lugar, el VIP entrante mitiga el paquete en su memoria del paquete hasta que algunos buffers estén otra vez disponibles para la interfaz saliente. Esto se llama almacenamiento en búfer en lado de recepción.

Utilice el comando show controllers vip accumulator de marcar el estatus de almacenamiento en búfer en lado de recepción. El estatus indica:

• El número de interfaces de salida presenta en el router.

• Cuántos paquetes el VIP tiene el Rx protegido para estas interfaces.

• Porqué el VIP tiene el Rx protegido.

• Cuántos paquetes descartó el VIP y por qué.

Funcionamientos VIP en la utilización de la CPU del 99%

Una consecuencia del almacenamiento en búfer del lado Rx es que el VIP se ejecuta con un 99 por ciento de utilización de la CPU. El VIP monitorea continuamente el estatus del txqueue de la interfaz de salida y, tan pronto como haya un almacén libre, copia el paquete sobre el cbus en el txqueue.

No hay nada que alarma en sí mismo cuando el VIP se ejecuta en el 99% cuando almacenamiento en memoria intermedia Rx ocurre. No significa que el VIP esté sobrecargado. Si el VIP recibe algo más importante hacer (por ejemplo, otro paquete a conmutar), esto no es afectada por CPU elevada.

Aquí está una prueba simple que usted puede hacer en el laboratorio para ilustrar esto:

El serial 2/0/0 tiene una velocidad del reloj del kbps 128, y recibe el tráfico en la línea tarifa. El tráfico se conmuta al serial 10/0 donde está 64 kbps la velocidad del reloj, y la Estrategia de almacenamiento en cola es (Primero en Entrar, Primero en Salir FIFO). La única opción es suprimir los paquetes.

router#show controller cbus 

MEMD at 40000000, 8388608 bytes (unused 697376, recarves 6, lost 0) 

RawQ 48000100, ReturnQ 48000108, EventQ 48000110 

BufhdrQ 48000130 (21 items), LovltrQ 48000148 (15 items, 2016 bytes) 

IpcbufQ 48000158 (24 items, 4096 bytes) 

IpcbufQ_classic 48000150 (8 items, 4096 bytes) 

3570 buffer headers (48002000 - 4800FF10) 

pool0: 8 buffers, 256 bytes, queue 48000138 

pool1: 2940 buffers, 1536 bytes, queue 48000140 

pool2: 550 buffers, 4512 bytes, queue 48000160 

pool3: 4 buffers, 4544 bytes, queue 48000168 

slot2: VIP2, hw 2.11, sw 22.20, ccb 5800FF40, cmdq 48000090, vps 8192 

software loaded from system 

IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE 
SOFTWARE (fc1) 

ROM Monitor version 122.0 

Mx Serial(4), HW Revision 0x3, FW Revision 1.45 

Serial2/0/0, applique is V.35 DCE 

received clockrate 2015232 

gfreeq 48000140, lfreeq 480001D0 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 16, maxrxcurr 293 

txq 48001A00, txacc 48001A02 (value 294), txlimit 294 

Serial2/0/1, applique is V.35 DTE 

received clockrate 246 

gfreeq 48000140, lfreeq 480001D8 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48001A08, txacc 48001A0A (value 6), txlimit 6 

Serial2/0/2, applique is Universal (cable unattached) 

received clockrate 246 

gfreeq 48000140, lfreeq 480001E0 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48001A10, txacc 48001A12 (value 6), txlimit 6 

Serial2/0/3, applique is Universal (cable unattached) 

received clockrate 246 

gfreeq 48000140, lfreeq 480001E8 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48001A18, txacc 48001A1A (value 6), txlimit 6 

slot10: FSIP, hw 1.12, sw 20.09, ccb 5800FFC0, cmdq 480000D0, vps 8192 

software loaded from system 

Serial10/0, applique is V.35 DTE 

gfreeq 48000140, lfreeq 48000208 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 1, maxrxcurr 1 

txq 48000210, txacc 480000B2 (value 2), txlimit 294 

Serial10/1, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000218 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000220, txacc 480000BA (value 6), txlimit 6 

Serial10/2, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000228 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000230, txacc 480000C2 (value 6), txlimit 6 

Serial10/3, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000238 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000240, txacc 480000CA (value 6), txlimit 6 

Serial10/4, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000248 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000250, txacc 480000D2 (value 6), txlimit 6 

Serial10/5, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000258 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000260, txacc 480000DA (value 6), txlimit 6 

Serial10/6, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000268 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000270, txacc 480000E2 (value 6), txlimit 6 

Serial10/7, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000278 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000280, txacc 480000EA (value 6), txlimit 6 

router# 

El valor 2 significa que solamente dos buffers están dejados. Almacenamiento en memoria intermedia Rx no hace cola los paquetes en el MEMD cuando el txacc es menos de 4.

El comando show controllers vip 2 tech-support del VIP muestra que se ejecuta en el 99% CPU:

router#show controllers vip 2 tech-support 

show tech-support from Slot 2: 

------------------ show version ------------------ 


Cisco Internetwork Operating System Software 

IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE 
SOFTWARE (fc1) 

Copyright (c) 1986-2000 by cisco Systems, Inc. 

Compiled Tue 18-Jul-00 22:03 by htseng 

Image text-base: 0x600108F0, data-base: 0x602E0000 


ROM: System Bootstrap, Version 11.1(4934) [pgreenfi 122], INTERIM SOFTWARE 


VIP-Slot2 uptime is 1 week, 23 hours, 27 minutes 

System returned to ROM by power-on 

Running default software 



cisco VIP2 (R4700) processor (revision 0x02) with 32768K bytes of memory. 

Processor board ID 00000000 

R4700 CPU at 100Mhz, Implementation 33, Rev 1.0, 512KB L2 Cache 

4 Serial network interface(s) 

Configuration register is 0x0 

... 

------------------ show process cpu ------------------ 

CPU utilization for five seconds: 99%/97%; one minute: 70%; five minutes: 69% 

El VIP se ejecuta en la utilización de la CPU del 99% aunque recibe solamente el kbps 128. Esto muestra que la utilización de la CPU no está conectada al número de paquetes por segundo. Esto es porque un VIP2 puede conmutar muchos más paquetes que esto. Es simplemente una muestra de almacenamiento en búfer en lado de recepción.

Para marcar qué almacenamiento en búfer en lado de recepción lo hace, ejecutar estos comandos:

router#show controllers vip 2 accumulator

show vip accumulator from Slot 2:

Buffered RX packets by accumulator:
...
Serial10/0: 
 MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps   
   No MEMD acc: 544980 in      
      Limit drops  : 2644102 normal pak drops, 80 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops   
   No MEMD buf: 0 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops
...
Interface x: 
MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps 
No MEMD acc: i in
      Limit drops  : j normal pak drops, k high prec pak drops      
      Buffer drops : l normal pak drops, m high prec pak drops
No MEMD buf: n in
      Limit drops  : o normal pak drops, p high prec pak drops      
      Buffer drops : q normal pak drops, r high prec pak drops

Clave	Descripción
a	Dirección del txacc en MEMD. Existe una cola de búfer de lado Rx para cada txacc en el sistema (hasta 4096).
b	Número de paquetes que son Rx protegidos.
c	Número de paquetes que el VIP cayó. Si hay bastantes búferes de memoria de paquetes, el VIP puede Almacenador intermediario de Rx hasta el segundo del tráfico. Sin embargo, si la interfaz está constantemente congestionada, no se pueden evitar las fallas.
d	Número de los paquetes de Rx protegido actualmente.
e	Cantidad de partículas actualmente almacenadas en la memoria intermedia Rx. Un paquete puede estar formado por varias partículas.
f	Límite suave, que es el número máximo de partículas cuando memoria VIP es baja.
g	Límite duro, que es el número máximo de partículas que se puedan utilizar en cualquier momento.
h	Velocidad de la interfaz saliente en kbps.
i	El número de paquetes Rx protegidos porque no hay txacc disponible en el MEMD. Esto significa que la cola de salida fue congestionada (no más de almacenes libres están disponibles en el Tx-queue). La solución a este problema es aumentar el ancho de banda de la interfaz de salida (si es posible).
j	El número de paquetes con la Prioridad IP con excepción de 6 o de 7 que no podrían ser enviados porque no hay acumulador MEMD, y se cae porque se ha alcanzado la suavidad o el límite de hardware de partículas.
k	Lo mismo que j, pero para los paquetes con la Prioridad IP 6 o 7 (red interna y red).
l	El número de paquetes con la Prioridad IP con excepción de 6 o de 7 que el VIP quiere al Almacenador intermediario de Rx, solamente descensos debido a una falta de almacenes libres en memoria del paquete. De los Cisco IOS Software Releases 12.0(13)S y 12.1(4) hacia adelante, usted puede también utilizar el comando show controller vip [all/slot-] packet-memory-drops de ver el número de paquetes caídos. En este caso, sería de ayuda una actualización de la memoria del paquete.
m	Lo mismo que l, pero para los paquetes con la Prioridad IP 6 o 7 (red interna y red).
n	El número de paquetes los intentos VIP al Almacenador intermediario de Rx porque no hay memoria intermedia MEMD, pero no puede hacer así que debido a los buffers de una falta de memoria de paquetes. Actualice memoria del paquete en este caso. De los Cisco IOS Software Releases 12.0(13)S y 12.1(4) hacia adelante, usted puede también utilizar el comando show controllers vip [all/slot-] packet-memory-drops de entender porqué se han caído los paquetes.
o	El número de paquetes Rx protegidos con la Prioridad IP con excepción de 6 o de 7 sin memoria intermedia MEMD se caen que porque se ha alcanzado el (f) suave o el límite duro (G). En esta situación, un RSP16 ayuda porque tiene más memoria MEMD (8 MB comparado al 2 MB para el RSP1, el RSP2, el RSP4, y el RSP7000). Usted puede también reducir el MTU de algunas interfaces (tales como atmósfera, POS, o FDDI) en este caso. Estas interfaces tienen generalmente un 4470-byte MTU, y menos buffers MEMD pueden ser afectados un aparato porque los buffers tienen que ser más grandes.
p	Lo mismo que o, pero para los paquetes con la Prioridad IP 6 o 7 (red interna y red).
q	El número de paquetes con la Prioridad IP con excepción de 6 o de 7 que el VIP intente al Almacenador intermediario de Rx porque no hay memoria intermedia MEMD, pero no puede hacer así que debido a los buffers de una falta de memoria de paquetes. Una actualización de memoria del paquete ayuda en este caso. De los Cisco IOS Software Releases 12.0(13)S y 12.1(4) hacia adelante, usted puede también utilizar el comando show controllers vip [all/slot-] packet-memory-drops de entender mejor porqué se han caído los paquetes.
r	Lo mismo que q, pero para los paquetes con la Prioridad IP 6 o 7 (red interna y red).

Si el router funciona con una versión del Cisco IOS Software anterior que el 12.0(13)O, 12.1(04)DB, 12.1(04)DC, 12.0(13)S, 12.1(4) 12.1(4)AA 12.1(4)T 012.0(13), o 12.0(13)SC, la salida del acumulador del [all/slot-] vip de los reguladores de la demostración proporciona una versión simplificada del antedicho. No tiene en cuenta el diverso precedences IP de los paquetes perdidos debido a almacenamiento en búfer en lado de recepción.

El resultado es similar al siguiente:

Serial10/0:
MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps
No MEMD acc: 544980 in, 2644182 limit drops, 0 no buffer
No MEMD buf: 0 in, 0 limit drops, 0 no buffer


Interface x: 
MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps 
No MEMD acc: i in, j+k limit drops, l+m no buffer 
No MEMD buf: n in, o+p limit drops, q+r no buffer 

Ejemplos de los buffers en la Cara de Rx

Ejemplo 1: El VIP en el slot 2 recibe el tráfico en un 128Kbps y lo rutea al serial 10/0 (64Kbps).

Serial10/0: 
 MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps   
   No MEMD acc: 544980 in      
      Limit drops : 2644102 normal pak drops, 80 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops   
   No MEMD buf: 0 in      
      Limit drops : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 

• Aquí, 544980 paquetes son con éxito Rx protegido y se caen 2644182. 80 de los 2644182 de los paquetes se cae que tenían una Prioridad IP de 6 o 7.

• 126 paquetes son actualmente Rx protegido y utilizan 378 partículas.

• Todos los paquetes son Rx protegidos debido a una falta de almacén libre en el Tx-queue en el MEMD. Esto significa que la interfaz de salida está congestionada. Los descensos ocurren porque el número máximo de paquetes Rx protegidos se alcanza. La solución típica es actualizar el ancho de banda de la interfaz de salida, reencamina un cierto tráfico para congestionar la interfaz de salida menos, o habilitar alguno que hace cola para caer el tráfico menos importante.

Ejemplo 2: Buffers de la Cara de Rx sin los descensos.

ATM1/0: 
MEMD txacc 0x0082: 203504 in, 0 drops (0 paks, 0/81/37968 bufs) 155520kbps 
No MEMD acc: 85709 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 
No MEMD buf: 117795 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 

• En este ejemplo, 85709 paquetes son Rx protegidos porque se congestiona el ATM1/0 pero no se cae ningunos paquetes.

• 117795 paquetes son Rx protegidos porque el VIP no puede conseguir memoria intermedia MEMD. No se cae ningunos paquetes. Una solución típica es disminuir algunos de los MTU para poder afectar un aparato más buffers MEMD. También ayudas Un RSP8.

Ejemplo 3: Local Switching.

SRP0/0/0: 

 local txacc 0x1A02: 2529 in, 0 drops (29 paks, 32/322/151855 bufs) 622000kbps 

El txacc local significa que esta interfaz de salida está en el mismo VIP que la interfaz donde se reciben los paquetes. Estos paquetes se conmutan localmente, pero se congestiona la interfaz de salida (en este caso, el srp 0/0/0). 2529 paquetes son Rx protegidos, y no se cae ningunos paquetes.

Ejemplo 4: Colas de administración del tráfico delanteras.

router#show controllers vip 2 accumulator
Buffered RX packets by accumulator: 
 Forward queue 0 : 142041 in, 3 drops (0 paks, 0/24414/24414 bufs) 100000kbps   
   No MEMD buf: 142041 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 3 normal pak drops, 0 high prec pak drops 
 Forward queue 9 : 68 in, 0 drops (0 paks, 0/15/484 bufs) 1984kbps   
   No MEMD buf: 68 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 
 Forward queue 13: 414 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps   
   No MEMD buf: 414 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 
 Forward queue 14: 46 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps   
   No MEMD buf: 46 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops

Algunos paquetes no pueden ser conmutados por distribución. En este caso, el VIP tiene que remitir los paquetes a la cola sin procesar del RSP, que entonces toma la decisión de Switching. Cuando los paquetes no se pueden copiar inmediatamente en el MEMD, los Rx-buffers VIP ellos y no pierden de vista cuántos paquetes son Rx protegidos por la interfaz de entrada.

Las colas de reenvío de 0 a 7 corresponden al primer adaptador de puerto (PA) y las colas de 8 a 15 corresponden al segundo PA.

Número de cola de reenvió	… muestra el número de paquetes Rx protegidos que se reciban en…
0	primer desaguadero del primer adaptador de puerto (PA)
8	primer desaguadero del segundo adaptador de puerto (PA)
9	Segundo desaguadero del segundo PA

Otras causas de uso intensivo de CPU en VIP

Cuando almacenamiento en búfer en lado de recepción se encuentra para estar inactivo, uno de estos factores puede causar CPU elevada la utilización en el VIP:

• Utilización de la CPU del 99% en el VIP, causado por el Distributed Traffic Shaping

  Cuando se configura el Control de tráfico distribuido (dTS), la CPU VIP salta hasta el 99% tan pronto como un paquete ingrese la cola del dTS.

  Ésta es la correcta y la conducta esperada. Cuando se configura el dTS, la CPU VIP hace girar para marcar si la próxima vez que llega el intervalo (Tc) cuando el CPU no está ocupado (es decir, cuando no hay tráfico). Si no, la verificación se lleva a cuestas en las rutinas de la interrupción tx/rx. Usted hace girar el CPU solamente cuando no está ocupado. Por lo tanto, el funcionamiento no es afectado.

  ¿Para entender lo que significa el “intervalo de tiempo siguiente”, vea cuál es un token bucket?

  Nota: El modelado de tráfico llega a ser activo solamente cuando tiene que enviar a la cola un paquete en la cola de modelado. Es decir cuando la cantidad de tráfico excede la velocidad de modelado. Esto explica porqué la CPU VIP no es siempre los 99% cuando se configura el dTS. Para más información sobre el dTS, vea:

  • Modelado del tráfico distribuido

  • Configurar el Distributed Traffic Shaping

• CPU elevada utilización en el VIP causado por los accesos de memoria espurios y los errores de alineación

  Los errores de alineación y los accesos de memoria espurios son averiados las fallas de software que son corregidas por el Cisco IOS Software sin la necesidad de causar un crash el VIP. Si aparecen estos errores con frecuencia, hace el sistema operativo hacer muchas correcciones que puedan llevar CPU elevada a la utilización.

  Para más información sobre los errores de alineación y los accesos de memoria espurios, vea los accesos espúreos, los errores de alineación, y las interrupciones espúreas del troubleshooting.

  Para marcar para saber si hay accesos de memoria espurios y errores de alineación, utilice el comando show alignment. Un ejemplo de tal error parece esto:

  VIP-Slot1#show alignment
  No alignment data has been recorded.
  No spurious memory references have been recorded.

Las otras causas CPU elevada de la utilización pueden ser la cantidad y el fragmento de las características distribuidas se habilitan que. Si usted sospecha que ésta podría ser la razón, o si usted no puede identificar las causas unas de los para CPU elevada la utilización explicada en este documento, abra una solicitud de servicio con el Centro de Asistencia Técnica de Cisco (TAC).

Información para recopilar si abre un pedido de servicio del TAC

Si usted todavía necesita la ayuda después de que usted siga los pasos de Troubleshooting arriba y quiera abrir una solicitud de servicio (clientes registrados solamente) con el TAC de Cisco, esté seguro de incluir esta información:

Salida del comando show controllers vip [all/slot-] accumulator Salida del comando show technical-support del RSP y del VIP relevantes Adjunte los datos recolectados a su pedido de servicio en formato de texto sin comprimir (.txt). Para adjuntar la información a su solicitud de servicio, cárguela a través de la Herramienta de Solicitud de Servicio TAC (sólo para clientes registrados). Si usted no puede acceder la herramienta de la solicitud de servicio, usted puede adjuntar la información pertinente a su solicitud de servicio, y la envía a attach@cisco.com con su número de la solicitud de servicio en el asunto de su mensaje. Nota: No recargue por favor manualmente o ciclo de la potencia el router antes de que usted recoja la información antedicha (a menos que esté requerido para restablecer la operación de la red), porque ésta puede hacer la información importante ser perdido que es necesaria determinar la causa raíz del problema.

Información Relacionada

• Soporte de productos de los routeres Cisco
• Alertas y Troubleshooting: Cisco 7500 Series Routers
• Soporte Técnico y Documentación - Cisco Systems