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

Introducción

Este documento explica porqué la CPU del procesador de la Interfaz versátil (VIP) se ejecuta en el 99%, y cuáles son almacenadores intermediarios del Rx-lado.

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

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

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).

El procesador entrante de la Interfaz versátil (VIP) no cae el paquete inmediatamente. En lugar, protege el paquete en su memoria del paquete hasta que los almacenadores intermediarios 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 (RSPs) está conectada con dos CyBuses (véase el cuadro 1).

Cuadro 1 – Arquitectura de las Cisco 7500 Series

Tipos de 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 almacenadores intermediarios se utilizan para los paquetes proceso-cambiados. Usted puede ver estos almacenadores intermediarios en la salida de los 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 mucha proceso-transferencia. 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:

  • Un broadcast storm

  • Inestabilidad en la red que causa las actualizaciones de la encaminamiento

  • Un ataque de la “negación de servicio” (DOS)

  • Una característica que no se utiliza en la trayectoria de la rápido-transferencia (por ejemplo, X.25)

  • Paquetes IP con las opciones.

  Para la información sobre cómo resolver problemas la transferencia de proceso excesiva, 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 almacenadores intermediarios RSP (MEMD)

  El tamaño MEMD es fijo en el 2 MB en el RSP7000, el RSP1, el RSP2, y el RSP4. En el RSP8 y el RSP16, el tamaño MEMD es 8 MB. MEMD se distribuye entre todos los interfaces a la hora del bootup, cuando hay una inserción y un retiro en línea (OIR), una recarga del microcódigo, un cambio del Maximum Transmission Unit (MTU), o un complejo del cbus. Para más información sobre el complejo del cbus, refiérase a qué causa un "%RSP-3-RESTART: complejo del cbus”?. Usted puede utilizar el comando show controllers cbus de controlar el estatus de los almacenadores intermediarios MEMD.

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

  • Una cola libre local (lfreeq) — Se asigna a cada interfaz, y se utiliza para los paquetes recibidos en este interfaz.

  • Una cola libre global (gfreeq) — También se afecta un aparato, y un 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 este interfaz.

  • El acumulador del transmitir (txacc) — Representa el número de elementos en la cola de transmisión de la interfaz de salida (txqueue). Cuando el acumulador del transmitir (txacc) iguala el límite del transmitir (txlimit), se liberan todos los almacenadores intermediarios. 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 un 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 activa la transferencia distribuida, porque almacenamiento en búfer en lado de recepción ocurre generalmente cuando un paquete sigue este tipo de trayecto de Switching. Diversos decorados 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 del puerto (PA) y se traslada a un almacén intermedio del paquete en memoria del paquete.

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

  • Si el VIP puede tomar la decisión de Switching y la interfaz saliente está en el mismo VIP, el paquete se envía en la interfaz de salida. El paquete reputa “localmente cambiado” en el VIP, porque no cruza el cbus.

  • Si el VIP puede tomar la decisión de Switching y la interfaz saliente está en otra ranura, el VIP intenta copiar el paquete sobre el cbus en el txqueue (en 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 hace cola se configura en la interfaz saliente, el VIP transfiere el paquete en el txqueue en MEMD, y el paquete es tirado inmediatamente de la cola por el código de espera.

    • 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 espera VIP-basada, el paquete se copia en 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, el interfaz no cae el paquete inmediatamente (esto es qué sucede normalmente con el primero en entrar, primero en salir cuando se congestiona una interfaz de salida). En lugar, el VIP entrante protege el paquete en su memoria del paquete hasta que algunos almacenadores intermediarios 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 controlar 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 Rx-ha protegido para estos interfaces.

• Porqué el VIP Rx-ha protegido.

• Cuántos paquetes el VIP cayó, y porqué.

Funcionamientos VIP en la utilización CPU del 99%

Una consecuencia de almacenamiento en búfer en lado de recepción es que el VIP se ejecuta en la utilización CPU del 99%. El VIP vigila 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 cambiar), 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 un índice de reloj del Kbps 128, y recibe el tráfico en la línea tarifa. El tráfico se cambia al serial 10/0 donde está 64 Kbps la tarifa de reloj, y la Estrategia de almacenamiento en cola es primero en entrar, primero en salir. La única opción es caer 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 almacenadores intermediarios están dejados. Almacenamiento en memoria intermedia Rx no hace cola los paquetes en MEMD cuando es el txacc menos de 4.

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

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 CPU del 99% aunque recibe solamente el Kbps 128. Esto muestra que la utilización CPU no está conectada al número de paquetes por segundo. Esto es porque un VIP2 puede cambiar muchos más paquetes que esto. Es simplemente una muestra de almacenamiento en búfer en lado de recepción.

Para controlar 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	Direccionamiento del txacc en MEMD. Hay una cola del almacenador intermediario del Rx-lado para cada txacc en el sistema (hasta 4096).
b	Número de paquetes Rx-se protegen que.
c	Número de paquetes que el VIP cayó. Si hay bastantes búferes de memoria de paquetes, el VIP puede Rx-almacenador intermediario hasta el segundo del tráfico. Sin embargo, si el interfaz se congestiona continuamente, no es posible evitar los descensos.
d	Número de paquetes Rx-protegidos actualmente.
e	Número de partículas Rx-protegidas actualmente. Un paquete se puede hacer de las partículas múltiples.
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	La velocidad de la interfaz saliente en el Kbps.
i	El número de paquetes Rx-protegidos porque no hay txacc disponible en MEMD. Esto significa que la cola de salida fue congestionada (no más de almacenes libres están disponibles en la tx-cola). 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 el Rx-almacenador intermediario, 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, una mejora de memoria del paquete ayuda.
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 el Rx-almacenador intermediario de los intentos VIP porque no hay memoria intermedia MEMD, pero no puede hacer tan debido a los almacenadores intermediarios 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 algunos interfaces (tales como atmósfera, posición, o FDDI) en este caso. Estos interfaces tienen generalmente un MTU 4470-byte, y menos almacenadores intermediarios MEMD pueden ser afectados un aparato porque los almacenadores intermediarios 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 el Rx-almacenador intermediario porque no hay memoria intermedia MEMD, pero no puede hacer tan debido a los almacenadores intermediarios de una falta de memoria de paquetes. Una mejora 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 de software del Cisco IOS 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 a una versión simplificada del antedicho. No tiene en cuenta las diversas precedencias IP de los paquetes eliminados 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 almacenadores intermediarios en el Rx-lado

Ejemplo 1: El VIP en la ranura 2 recibe el tráfico en un 128Kbps y lo encamina 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 Rx-se protegen con éxito y se caen 2644182. 80 paquetes fuera de los 2644182 se caen que tenían una Prioridad IP de 6 o 7.

• 126 paquetes Rx-se protegen actualmente y utilizan 378 partículas.

• Todos los paquetes Rx-se protegen debido a una falta de almacén libre en la tx-cola en 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 activar alguno que hace cola para caer el tráfico menos importante.

Ejemplo 2: almacenadores intermediarios del Rx-lado 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, Rx-se protegen 85709 paquetes porque se congestiona el ATM1/0 pero no se cae ningunos paquetes.

• Rx-se protegen 117795 paquetes porque el VIP no puede conseguir memoria intermedia MEMD. No se cae ningunos paquetes. Una solución típica es disminuir algo del MTUs para poder afectar un aparato más almacenadores intermediarios MEMD. También ayudas Un RSP8.

Ejemplo 3: Transferencia local.

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 el interfaz donde se reciben los paquetes. Estos paquetes se cambian localmente, pero se congestiona la interfaz de salida (en este caso, el srp 0/0/0). Rx-se protegen 2529 paquetes, 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 distribuir-ser cambiados. 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 MEMD, los Rx-almacenadores intermediarios VIP él y no pierden de vista cuántos paquetes Rx-se protegen por la interfaz de entrada.

Las colas de administración del tráfico delanteras 0-7 están para el primer adaptador del puerto (PA) y 8-15 para el segundo PA.

Número delantero de la cola	… muestra el número de paquetes Rx-protegidos que se reciban en…
0	primer desaguadero del primer adaptador del puerto (PA)
8	primer desaguadero del segundo 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 CPU del 99% en el VIP, causado formando del tráfico distribuido

  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 controlar si la próxima vez que llega el intervalo (Tc) cuando la CPU no está ocupada (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 la CPU solamente cuando no está ocupada. Por lo tanto, el funcionamiento no es afectado.

  ¿Para entender lo que significa el “intervalo de tiempo siguiente”, vea cuál es un compartimiento simbólico?

  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:

  • El formar del tráfico distribuido

  • Configurar formar del tráfico distribuido

• 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 software del Cisco IOS 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 controlar 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 activan 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 la 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, cargúela por teletratamiento a través de la herramienta de la solicitud de servicio de TAC (clientes registrados solamente). Si usted no puede tener acceso a 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 potencia-ciclo 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

• Asistencia técnica del Routers de Cisco
• Troubleshooting y alertas: Cisco 7500 Series Router
• Soporte Técnico y Documentación - Cisco Systems

Historial de revisiones